From pbansal at openjdk.java.net Sun May 2 06:39:01 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Sun, 2 May 2021 06:39:01 GMT Subject: RFR: 8265291: Error in Javadoc for doAccessibleAction API in AccessibleJSlider class Message-ID: There is a small error in javadoc for doAccessibleAction function added in AccessibleJSlider class under JDK-8262981. The documentation says that the API returns true always, whereas it can return both true or false depending upon the parameter value, same as is the case with same API in AccessibleJSpinner. This error happened do to an oversight and current fix corrects the error. ------------- Commit messages: - 8265291: Error in Javadoc for doAccessibleAction API in AccessibleJSlider class Changes: https://git.openjdk.java.net/jdk/pull/3832/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3832&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265291 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3832.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3832/head:pull/3832 PR: https://git.openjdk.java.net/jdk/pull/3832 From trebari at openjdk.java.net Mon May 3 09:00:01 2021 From: trebari at openjdk.java.net (Tejpal Rebari) Date: Mon, 3 May 2021 09:00:01 GMT Subject: RFR: 8264950: Set opaque for JTooltip in config file of NimbusLookAndFeel Message-ID: Set the opaque property for JToolTip in config file (skin.laf) of NimbusLookAndFeel instead of setting up in the SynthToolTipUI. This is related to the discussion on PR https://github.com/openjdk/jdk/pull/3167. ------------- Commit messages: - set opaque for JTooltip in config file Changes: https://git.openjdk.java.net/jdk/pull/3837/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3837&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264950 Stats: 3 lines in 3 files changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3837.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3837/head:pull/3837 PR: https://git.openjdk.java.net/jdk/pull/3837 From azvegint at openjdk.java.net Mon May 3 16:57:55 2021 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Mon, 3 May 2021 16:57:55 GMT Subject: RFR: 8265291: Error in Javadoc for doAccessibleAction API in AccessibleJSlider class In-Reply-To: References: Message-ID: On Sun, 2 May 2021 06:09:23 GMT, Pankaj Bansal wrote: > There is a small error in javadoc for doAccessibleAction function added in AccessibleJSlider class under JDK-8262981. The documentation says that the API returns true always, whereas it can return both true or false depending upon the parameter value, same as is the case with same API in AccessibleJSpinner. This error happened do to an oversight and current fix corrects the error. Looks like it requires CSR. ------------- Marked as reviewed by azvegint (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3832 From pbansal at openjdk.java.net Mon May 3 17:12:47 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Mon, 3 May 2021 17:12:47 GMT Subject: RFR: 8265291: Error in Javadoc for doAccessibleAction API in AccessibleJSlider class In-Reply-To: References: Message-ID: On Mon, 3 May 2021 16:55:07 GMT, Alexander Zvegintsev wrote: > Looks like it requires CSR. I think CSR is not required in this case. CSR would have been required if return type was being changed. Here the change only says that the function can return both true or false instead of just true, but the return type is not being changed. I will try to get clarity on this and proceed accordingly. ------------- PR: https://git.openjdk.java.net/jdk/pull/3832 From azvegint at openjdk.java.net Mon May 3 18:28:56 2021 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Mon, 3 May 2021 18:28:56 GMT Subject: RFR: 8265291: Error in Javadoc for doAccessibleAction API in AccessibleJSlider class In-Reply-To: References: Message-ID: <5KYipBiMBGLS5iJD79Xh1yBkyhvnH4RvvuWb8ldvILU=.9665f11f-80a0-4ecf-970c-f3fe93afb1f3@github.com> On Mon, 3 May 2021 17:09:59 GMT, Pankaj Bansal wrote: > > Looks like it requires CSR. > > I think CSR is not required in this case. CSR would have been required if return type was being changed. Here the change only says that the function can return both true or false instead of just true, but the return type is not being changed. I will try to get clarity on this and proceed accordingly. https://wiki.openjdk.java.net/display/csr/CSR+FAQs: > Q: If the text of the javadoc of a public exported API is changing, is a CSR request needed? A: A CSR request is required if the specification of a public exported API. Not all javadoc updates are specification changes. For example, typo fixes and rephrasings that do not alter the semantics of the API in question do not require CSR review. It looks like a javadoc which alters semantics of the API. This method can be used in subclass and probably would count as `public exported API`, but I am not sure here. ------------- PR: https://git.openjdk.java.net/jdk/pull/3832 From kizune at openjdk.java.net Mon May 3 19:36:02 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Mon, 3 May 2021 19:36:02 GMT Subject: RFR: 8266249: javax/swing/JPopupMenu/7156657/bug7156657.java fails on macOS Message-ID: Fixed popup position taking into account its offset Added a lot of screenshots taking to better understand failures should they happen down the line ------------- Commit messages: - 8266249: javax/swing/JPopupMenu/7156657/bug7156657.java fails on macOS Changes: https://git.openjdk.java.net/jdk/pull/3844/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3844&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266249 Stats: 41 lines in 1 file changed: 40 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3844.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3844/head:pull/3844 PR: https://git.openjdk.java.net/jdk/pull/3844 From serb at openjdk.java.net Mon May 3 21:30:51 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 3 May 2021 21:30:51 GMT Subject: RFR: 8264950: Set opaque for JTooltip in config file of NimbusLookAndFeel In-Reply-To: References: Message-ID: On Mon, 3 May 2021 08:54:19 GMT, Tejpal Rebari wrote: > Set the opaque property for JToolTip in config file (skin.laf) of NimbusLookAndFeel instead of setting up in the SynthToolTipUI. > This is related to the discussion on PR https://github.com/openjdk/jdk/pull/3167. Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3837 From pbansal at openjdk.java.net Tue May 4 03:29:50 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Tue, 4 May 2021 03:29:50 GMT Subject: RFR: 8264950: Set opaque for JTooltip in config file of NimbusLookAndFeel In-Reply-To: References: Message-ID: On Mon, 3 May 2021 08:54:19 GMT, Tejpal Rebari wrote: > Set the opaque property for JToolTip in config file (skin.laf) of NimbusLookAndFeel instead of setting up in the SynthToolTipUI. > This is related to the discussion on PR https://github.com/openjdk/jdk/pull/3167. Marked as reviewed by pbansal (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3837 From trebari at openjdk.java.net Tue May 4 04:56:51 2021 From: trebari at openjdk.java.net (Tejpal Rebari) Date: Tue, 4 May 2021 04:56:51 GMT Subject: Integrated: 8264950: Set opaque for JTooltip in config file of NimbusLookAndFeel In-Reply-To: References: Message-ID: <7uGmpa-8d3gSupoqAQ982G5bGdfnXq3EJhfxwIgqluc=.dedd0c17-cc86-499a-8682-f061f8b68975@github.com> On Mon, 3 May 2021 08:54:19 GMT, Tejpal Rebari wrote: > Set the opaque property for JToolTip in config file (skin.laf) of NimbusLookAndFeel instead of setting up in the SynthToolTipUI. > This is related to the discussion on PR https://github.com/openjdk/jdk/pull/3167. This pull request has now been integrated. Changeset: 30ccd808 Author: Tejpal Rebari URL: https://git.openjdk.java.net/jdk/commit/30ccd8081b3b82c04203a72c59d12a8c0a24b0c0 Stats: 3 lines in 3 files changed: 0 ins; 1 del; 2 mod 8264950: Set opaque for JTooltip in config file of NimbusLookAndFeel Reviewed-by: serb, pbansal ------------- PR: https://git.openjdk.java.net/jdk/pull/3837 From pbansal at openjdk.java.net Tue May 4 10:08:49 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Tue, 4 May 2021 10:08:49 GMT Subject: RFR: 8266249: javax/swing/JPopupMenu/7156657/bug7156657.java fails on macOS In-Reply-To: References: Message-ID: On Mon, 3 May 2021 19:30:07 GMT, Alexander Zuev wrote: > Fixed popup position taking into account its offset > Added a lot of screenshots taking to better understand failures should they happen down the line As this is an intermittent failure (failed once in 40 iterations as mentioned in JBS), can you please run multiple iterations of the test in CI system without JTREG_RETRY_COUNT option to confirm there is no failure now? ------------- PR: https://git.openjdk.java.net/jdk/pull/3844 From kizune at openjdk.java.net Tue May 4 21:30:12 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Tue, 4 May 2021 21:30:12 GMT Subject: RFR: 8266249: javax/swing/JPopupMenu/7156657/bug7156657.java fails on macOS [v2] In-Reply-To: References: Message-ID: <513ojy1NZgCCFnfgG93zQT3W0x3RgvZcAkzKmQQLI3U=.9ab34682-3d9e-464e-b71e-cdffdf22aa9b@github.com> > Fixed popup position taking into account its offset > Added a lot of screenshots taking to better understand failures should they happen down the line Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Added delay so frame repainting finished ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3844/files - new: https://git.openjdk.java.net/jdk/pull/3844/files/2c8fd384..f3589c68 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3844&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3844&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3844.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3844/head:pull/3844 PR: https://git.openjdk.java.net/jdk/pull/3844 From kizune at openjdk.java.net Wed May 5 02:25:51 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Wed, 5 May 2021 02:25:51 GMT Subject: RFR: 8266249: javax/swing/JPopupMenu/7156657/bug7156657.java fails on macOS In-Reply-To: References: Message-ID: On Tue, 4 May 2021 10:05:33 GMT, Pankaj Bansal wrote: > As this is an intermittent failure (failed once in 40 iterations as mentioned in JBS), can you please run multiple iterations of the test in CI system without JTREG_RETRY_COUNT option to confirm there is no failure now? Added test run link to the bug. ------------- PR: https://git.openjdk.java.net/jdk/pull/3844 From jdv at openjdk.java.net Wed May 5 06:10:53 2021 From: jdv at openjdk.java.net (Jayathirth D V) Date: Wed, 5 May 2021 06:10:53 GMT Subject: RFR: 8265291: Error in Javadoc for doAccessibleAction API in AccessibleJSlider class In-Reply-To: References: Message-ID: On Sun, 2 May 2021 06:09:23 GMT, Pankaj Bansal wrote: > There is a small error in javadoc for doAccessibleAction function added in AccessibleJSlider class under JDK-8262981. The documentation says that the API returns true always, whereas it can return both true or false depending upon the parameter value, same as is the case with same API in AccessibleJSpinner. This error happened do to an oversight and current fix corrects the error. Marked as reviewed by jdv (Reviewer). It is a behavioral change from Javadoc and it needs CSR. ------------- PR: https://git.openjdk.java.net/jdk/pull/3832 From psadhukhan at openjdk.java.net Wed May 5 06:22:52 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 5 May 2021 06:22:52 GMT Subject: =?utf-8?q?Integrated=3A_8264398=3A_BevelBorderUIReso?= =?utf-8?b?dXJjZeKAiyhpbnQsIENvbG9yLCBDb2xvcikgYW5kIEJldmVsQm9kZXIoaW50?= =?utf-8?q?=2C_Color=2C_Color=29_spec_should_clarify_about_usage_of_highli?= =?utf-8?q?ght_and_shadow_color?= In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 12:20:54 GMT, Prasanta Sadhukhan wrote: > The current spec for javax/swing/plaf/BorderUIResource.BevelBorderUIResource.html(int,java.awt.Color,java.awt.Color) does not clearly specify the usage of color for hightlight and shadow as there are outer/inner hightlight and outer/inner shadow. > Updated spec to clarify the same. This pull request has now been integrated. Changeset: b71f85ad Author: Prasanta Sadhukhan URL: https://git.openjdk.java.net/jdk/commit/b71f85ad9d5dbd59b1d279148bc65ac26309a942 Stats: 10 lines in 2 files changed: 8 ins; 0 del; 2 mod 8264398: BevelBorderUIResource?(int, Color, Color) and BevelBoder(int, Color, Color) spec should clarify about usage of highlight and shadow color Reviewed-by: serb ------------- PR: https://git.openjdk.java.net/jdk/pull/3305 From psadhukhan at openjdk.java.net Wed May 5 07:09:20 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 5 May 2021 07:09:20 GMT Subject: RFR: 8265528: Specification of BasicSplitPaneDivider::getMinimumSize, getPreferredSize doesn't match with its behavior. Message-ID: The current specification of these 2 methods api/java.desktop/javax/swing/plaf/basic/BasicSplitPaneDivider.html#getPreferredSize(). and api/java.desktop/javax/swing/plaf/basic/BasicSplitPaneDivider.html#getMinimumSize() does not specify correct return values. Also, the spec is not very intuitive and clear. Rectified the spec to specify correct behaviour. ------------- Commit messages: - 8265528: Specification of BasicSplitPaneDivider::getMinimumSize,getPreferredSize doesn't match with its behavior. Changes: https://git.openjdk.java.net/jdk/pull/3870/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3870&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265528 Stats: 17 lines in 1 file changed: 14 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3870.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3870/head:pull/3870 PR: https://git.openjdk.java.net/jdk/pull/3870 From kizune at openjdk.java.net Wed May 5 13:38:50 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Wed, 5 May 2021 13:38:50 GMT Subject: RFR: 8265528: Specification of BasicSplitPaneDivider::getMinimumSize, getPreferredSize doesn't match with its behavior. In-Reply-To: References: Message-ID: On Wed, 5 May 2021 07:01:34 GMT, Prasanta Sadhukhan wrote: > The current specification of these 2 methods > api/java.desktop/javax/swing/plaf/basic/BasicSplitPaneDivider.html#getPreferredSize(). > and > api/java.desktop/javax/swing/plaf/basic/BasicSplitPaneDivider.html#getMinimumSize() > does not specify correct return values. Also, the spec is not very intuitive and clear. > > Rectified the spec to specify correct behaviour. Marked as reviewed by kizune (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3870 From psadhukhan at openjdk.java.net Wed May 5 14:55:59 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 5 May 2021 14:55:59 GMT Subject: RFR: 8265528: Specification of BasicSplitPaneDivider::getMinimumSize, getPreferredSize doesn't match with its behavior. In-Reply-To: References: Message-ID: On Wed, 5 May 2021 07:01:34 GMT, Prasanta Sadhukhan wrote: > The current specification of these 2 methods > api/java.desktop/javax/swing/plaf/basic/BasicSplitPaneDivider.html#getPreferredSize(). > and > api/java.desktop/javax/swing/plaf/basic/BasicSplitPaneDivider.html#getMinimumSize() > does not specify correct return values. Also, the spec is not very intuitive and clear. > > Rectified the spec to specify correct behaviour. csr https://bugs.openjdk.java.net/browse/JDK-8266541 ------------- PR: https://git.openjdk.java.net/jdk/pull/3870 From serb at openjdk.java.net Wed May 5 20:30:50 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 5 May 2021 20:30:50 GMT Subject: RFR: 8265528: Specification of BasicSplitPaneDivider::getMinimumSize, getPreferredSize doesn't match with its behavior. In-Reply-To: References: Message-ID: On Wed, 5 May 2021 07:01:34 GMT, Prasanta Sadhukhan wrote: > The current specification of these 2 methods > api/java.desktop/javax/swing/plaf/basic/BasicSplitPaneDivider.html#getPreferredSize(). > and > api/java.desktop/javax/swing/plaf/basic/BasicSplitPaneDivider.html#getMinimumSize() > does not specify correct return values. Also, the spec is not very intuitive and clear. > > Rectified the spec to specify correct behaviour. src/java.desktop/share/classes/javax/swing/plaf/basic/BasicSplitPaneDivider.java line 309: > 307: * > 308: * @return a {@code Dimension} object containing the preferred size of > 309: * {@code BasicSplitPaneDivider} I wonder how we usually specify the getPref/getMin methods. Do we really describe how it is implemented or just mention something like "Returns the minimum size for the XXX". ------------- PR: https://git.openjdk.java.net/jdk/pull/3870 From psadhukhan at openjdk.java.net Thu May 6 05:17:53 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 6 May 2021 05:17:53 GMT Subject: RFR: 8265528: Specification of BasicSplitPaneDivider::getMinimumSize, getPreferredSize doesn't match with its behavior. In-Reply-To: References: Message-ID: <7TzrlBF_O1SWHDclX4hCq_OvtW0lHivNt6-Cobwp_Us=.4b322ef7-a773-4e47-b7ba-97d4978d635f@github.com> On Wed, 5 May 2021 20:27:43 GMT, Sergey Bylokhov wrote: >> The current specification of these 2 methods >> api/java.desktop/javax/swing/plaf/basic/BasicSplitPaneDivider.html#getPreferredSize(). >> and >> api/java.desktop/javax/swing/plaf/basic/BasicSplitPaneDivider.html#getMinimumSize() >> does not specify correct return values. Also, the spec is not very intuitive and clear. >> >> Rectified the spec to specify correct behaviour. > > src/java.desktop/share/classes/javax/swing/plaf/basic/BasicSplitPaneDivider.java line 309: > >> 307: * >> 308: * @return a {@code Dimension} object containing the preferred size of >> 309: * {@code BasicSplitPaneDivider} > > I wonder how we usually specify the getPref/getMin methods. Do we really describe how it is implemented or just mention something like "Returns the minimum size for the XXX". There's instances of both so I took the liberty to err on the more elaborate way so as to not leave anything ambiguous. ------------- PR: https://git.openjdk.java.net/jdk/pull/3870 From serb at openjdk.java.net Thu May 6 06:07:54 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 6 May 2021 06:07:54 GMT Subject: RFR: 8265528: Specification of BasicSplitPaneDivider::getMinimumSize, getPreferredSize doesn't match with its behavior. In-Reply-To: <7TzrlBF_O1SWHDclX4hCq_OvtW0lHivNt6-Cobwp_Us=.4b322ef7-a773-4e47-b7ba-97d4978d635f@github.com> References: <7TzrlBF_O1SWHDclX4hCq_OvtW0lHivNt6-Cobwp_Us=.4b322ef7-a773-4e47-b7ba-97d4978d635f@github.com> Message-ID: <6iGHzsqt91EdCt7LeIyKJbpBHDR3VzNwiWQUSxXihnI=.bce8950a-b558-4b3f-86d9-b79f043ea18c@github.com> On Thu, 6 May 2021 05:14:42 GMT, Prasanta Sadhukhan wrote: >> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicSplitPaneDivider.java line 309: >> >>> 307: * >>> 308: * @return a {@code Dimension} object containing the preferred size of >>> 309: * {@code BasicSplitPaneDivider} >> >> I wonder how we usually specify the getPref/getMin methods. Do we really describe how it is implemented or just mention something like "Returns the minimum size for the XXX". > > There's instances of both so I took the liberty to err on the more elaborate way so as to not leave anything ambiguous. But then it will not be possible to change it in the future here or in any subclasses to say 2 pixels, etc. ------------- PR: https://git.openjdk.java.net/jdk/pull/3870 From psadhukhan at openjdk.java.net Thu May 6 06:10:54 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 6 May 2021 06:10:54 GMT Subject: RFR: 8265528: Specification of BasicSplitPaneDivider::getMinimumSize, getPreferredSize doesn't match with its behavior. In-Reply-To: <6iGHzsqt91EdCt7LeIyKJbpBHDR3VzNwiWQUSxXihnI=.bce8950a-b558-4b3f-86d9-b79f043ea18c@github.com> References: <7TzrlBF_O1SWHDclX4hCq_OvtW0lHivNt6-Cobwp_Us=.4b322ef7-a773-4e47-b7ba-97d4978d635f@github.com> <6iGHzsqt91EdCt7LeIyKJbpBHDR3VzNwiWQUSxXihnI=.bce8950a-b558-4b3f-86d9-b79f043ea18c@github.com> Message-ID: On Thu, 6 May 2021 06:04:58 GMT, Sergey Bylokhov wrote: >> There's instances of both so I took the liberty to err on the more elaborate way so as to not leave anything ambiguous. > > But then it will not be possible to change it in the future here or in any subclasses to say 2 pixels, etc. We can then add @implSpec if you wish ------------- PR: https://git.openjdk.java.net/jdk/pull/3870 From psadhukhan at openjdk.java.net Thu May 6 06:51:34 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 6 May 2021 06:51:34 GMT Subject: RFR: 8265528: Specification of BasicSplitPaneDivider::getMinimumSize, getPreferredSize doesn't match with its behavior. [v2] In-Reply-To: References: Message-ID: > The current specification of these 2 methods > api/java.desktop/javax/swing/plaf/basic/BasicSplitPaneDivider.html#getPreferredSize(). > and > api/java.desktop/javax/swing/plaf/basic/BasicSplitPaneDivider.html#getMinimumSize() > does not specify correct return values. Also, the spec is not very intuitive and clear. > > Rectified the spec to specify correct behaviour. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Add implSpec tag ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3870/files - new: https://git.openjdk.java.net/jdk/pull/3870/files/5e816095..eea67529 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3870&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3870&range=00-01 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3870.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3870/head:pull/3870 PR: https://git.openjdk.java.net/jdk/pull/3870 From trebari at openjdk.java.net Fri May 7 05:15:56 2021 From: trebari at openjdk.java.net (Tejpal Rebari) Date: Fri, 7 May 2021 05:15:56 GMT Subject: Integrated: 8049700: Deprecate obsolete classes and methods in javax/swing/plaf/basic In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 12:43:41 GMT, Tejpal Rebari wrote: > Please review the following fix for jdk17. > In this fix i have deprecated and marked for removal following classes and methods > public void intervalAdded(ListDataEvent e) > public void intervalRemoved(ListDataEvent e) > protected boolean lt(File a, File b) in BasicDirectoryModel.java > > inner class PropertyChangeHandler, VSBChangeListener, HSBChangeListener, > ViewportChangeHandler in BasicScrollPaneUI.java > inner class MouseInputHandler in BasicMenuItemUI.java > method BasicToolBarUI.java#createFloatingFrame > > From 8049700 not deprecated the paintText(Graphics g, JComponent c, Rectangle textRect, String text) method in BasicButtonUI as AquaButtonUI, MetalButtonUI and MetalToggleButtonUI overrides it. > Similarly not deprecated ChangeHandler of BasicMenuUI as AquaMenuUI and MotifMenuUI uses this class. This pull request has now been integrated. Changeset: ebb68d2b Author: Tejpal Rebari URL: https://git.openjdk.java.net/jdk/commit/ebb68d2b8652328b80780f6a39c78ff19f24136a Stats: 38 lines in 4 files changed: 31 ins; 0 del; 7 mod 8049700: Deprecate obsolete classes and methods in javax/swing/plaf/basic Reviewed-by: psadhukhan, prr, serb, azvegint, iris ------------- PR: https://git.openjdk.java.net/jdk/pull/1958 From jdv at openjdk.java.net Fri May 7 14:55:51 2021 From: jdv at openjdk.java.net (Jayathirth D V) Date: Fri, 7 May 2021 14:55:51 GMT Subject: RFR: 8266249: javax/swing/JPopupMenu/7156657/bug7156657.java fails on macOS [v2] In-Reply-To: <513ojy1NZgCCFnfgG93zQT3W0x3RgvZcAkzKmQQLI3U=.9ab34682-3d9e-464e-b71e-cdffdf22aa9b@github.com> References: <513ojy1NZgCCFnfgG93zQT3W0x3RgvZcAkzKmQQLI3U=.9ab34682-3d9e-464e-b71e-cdffdf22aa9b@github.com> Message-ID: <7negOpUa-l2El0BWo3QWM_9QhVSn2EhifV1qRD6ZmeY=.09ef6812-631d-4d40-9687-239d0bb426b0@github.com> On Tue, 4 May 2021 21:30:12 GMT, Alexander Zuev wrote: >> Fixed popup position taking into account its offset >> Added a lot of screenshots taking to better understand failures should they happen down the line > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Added delay so frame repainting finished LGTM. I had doubt whether we will have write access to test path to create new files in our CI systems, but it looks like we can. Verified it by making the test fail purposefully in our CI. ------------- Marked as reviewed by jdv (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3844 From kizune at openjdk.java.net Fri May 7 15:34:05 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Fri, 7 May 2021 15:34:05 GMT Subject: RFR: 8182043: Access to Windows Large Icons [v3] In-Reply-To: <3hQNodTn6s3lrpoRv7bTa-fDV4OBwdEiHiV_vo3zJQY=.f5f64501-eb98-4ffa-83b1-b3841abf290b@github.com> References: <3hQNodTn6s3lrpoRv7bTa-fDV4OBwdEiHiV_vo3zJQY=.f5f64501-eb98-4ffa-83b1-b3841abf290b@github.com> Message-ID: <1ZcgYG7cw2U5TiBBToj1CDopOE3ddTwVgTrPJ4_xiis=.25d36ebf-12e9-44e0-a4fd-008f95b8185f@github.com> On Fri, 30 Apr 2021 20:23:21 GMT, Alexey Ivanov wrote: >> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: >> >> Update src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp >> >> Select one icon at a time. >> >> Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> > > src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 267: > >> 265: * returned will be a multi-resolution icon image, >> 266: * which will allow better scaling with different >> 267: * magnification factors. > > I'm not sure what are the standard terms to refer to High DPI environments and the scale factors associated with High DPI. In Windows environment it is scaling size or scaling factor. On Mac it is called scaled resolution. So i would say scaling factor is an appropriate term. ------------- PR: https://git.openjdk.java.net/jdk/pull/2875 From psadhukhan at openjdk.java.net Fri May 7 16:03:52 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Fri, 7 May 2021 16:03:52 GMT Subject: RFR: 8266249: javax/swing/JPopupMenu/7156657/bug7156657.java fails on macOS [v2] In-Reply-To: <513ojy1NZgCCFnfgG93zQT3W0x3RgvZcAkzKmQQLI3U=.9ab34682-3d9e-464e-b71e-cdffdf22aa9b@github.com> References: <513ojy1NZgCCFnfgG93zQT3W0x3RgvZcAkzKmQQLI3U=.9ab34682-3d9e-464e-b71e-cdffdf22aa9b@github.com> Message-ID: On Tue, 4 May 2021 21:30:12 GMT, Alexander Zuev wrote: >> Fixed popup position taking into account its offset >> Added a lot of screenshots taking to better understand failures should they happen down the line > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Added delay so frame repainting finished I'm not sure about this change...Maybe changing frame location from (0,0) at l192 to middle of screen though selLocationRelativeTo() may be enough to make the test more stable in CI systems. ------------- PR: https://git.openjdk.java.net/jdk/pull/3844 From kizune at openjdk.java.net Fri May 7 17:39:10 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Fri, 7 May 2021 17:39:10 GMT Subject: RFR: 8182043: Access to Windows Large Icons [v3] In-Reply-To: <3hQNodTn6s3lrpoRv7bTa-fDV4OBwdEiHiV_vo3zJQY=.f5f64501-eb98-4ffa-83b1-b3841abf290b@github.com> References: <3hQNodTn6s3lrpoRv7bTa-fDV4OBwdEiHiV_vo3zJQY=.f5f64501-eb98-4ffa-83b1-b3841abf290b@github.com> Message-ID: On Fri, 30 Apr 2021 20:34:01 GMT, Alexey Ivanov wrote: >> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: >> >> Update src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp >> >> Select one icon at a time. >> >> Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> > > src/java.desktop/share/classes/sun/awt/shell/ShellFolder.java line 213: > >> 211: * Returns the icon of the specified size used to display this shell folder. >> 212: * >> 213: * @param size size of the icon > 0 (Valid range: 1 to 256) > > I'm unsure the valid range of 1 to 256 makes sense provided the icon smaller than 16?16 is never returned (on Windows at least). Well, user still can request 1x1 icon - we will return the multiresolution image with minimal (1x1) icon inside that will be scaled every time the actual painting occurs. The size will define the layout of the component with the icon and can be auto-generated from the user code so i do not see why we should limit the lowest requested size - especially in the shared instance that not only specific for Windows platform. > src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1193: > >> 1191: static Image getShell32Icon(int iconID, int size) { >> 1192: Toolkit toolkit = Toolkit.getDefaultToolkit(); >> 1193: String shellIconBPP = (String)toolkit.getDesktopProperty("win.icon.shellIconBPP"); > > Looks like these lines aren't used any more and should be removed too. Yes. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/2875 From kizune at openjdk.java.net Fri May 7 18:02:33 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Fri, 7 May 2021 18:02:33 GMT Subject: RFR: 8182043: Access to Windows Large Icons [v3] In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 20:54:01 GMT, Alexey Ivanov wrote: >> src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1146: >> >>> 1144: } >>> 1145: Map multiResolutionIcon = new HashMap<>(); >>> 1146: int start = size > MAX_QUALITY_ICON ? ICON_RESOLUTIONS.length - 1 : 0; >> >> Does it make sense to always start at zero? >> The icons of smaller size will never be used, will they? >> Thus it's safe to start at the index which corresponds to the requested size if `size` matches, or the index such as `ICON_RESOLUTIONS[index] < size && ICON_RESOLUTIONS[index + 1] > size`. > > This comment is also about the case of not fetching icons of sizes smaller than requested size. Sorry, missed that in my latest fix. Indeed there is no legitimate ways to set scaling factor to less than 100% on Windows so yes, omitting the icons that are less than expected size. As for starting the count from the correct index - to get the correct index we would have to traverse the array of possible resolutions anyways so there is no performance gain. ------------- PR: https://git.openjdk.java.net/jdk/pull/2875 From kizune at openjdk.java.net Fri May 7 21:35:45 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Fri, 7 May 2021 21:35:45 GMT Subject: RFR: 8266249: javax/swing/JPopupMenu/7156657/bug7156657.java fails on macOS [v2] In-Reply-To: References: <513ojy1NZgCCFnfgG93zQT3W0x3RgvZcAkzKmQQLI3U=.9ab34682-3d9e-464e-b71e-cdffdf22aa9b@github.com> Message-ID: On Fri, 7 May 2021 16:00:37 GMT, Prasanta Sadhukhan wrote: > I'm not sure about this change...Maybe changing frame location from (0,0) at l192 to middle of screen though selLocationRelativeTo() may be enough to make the test more stable in CI systems. The problem here is not only in location but in the screenshot taking area outside of the popup and analyzing it. That is one of the reasons why test is unreliable - it analyzes the wrong place. And moving frame to the different position will not help either - the problem is not that system menubar overlaps the popup - it does not, the problem is that we are catching part of the menubar because we do not adjust for the offset it introduces to the screen coordinates. Here's the screenshot, note that area we are analyzing is one outlined with cyan borders. By not adjusting the location we just catching random stuff. ![dev0scr0](https://user-images.githubusercontent.com/69642324/117507970-acfb9700-af3c-11eb-8791-a1fe62e140a9.png) ------------- PR: https://git.openjdk.java.net/jdk/pull/3844 From kizune at openjdk.java.net Sat May 8 00:19:22 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Sat, 8 May 2021 00:19:22 GMT Subject: RFR: 8182043: Access to Windows Large Icons [v4] In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 20:48:21 GMT, Alexey Ivanov wrote: >> Getting smaller icon is relevant in the case of the scaling. I do not think refactoring image caches from icons to multiresolution images will make code much cleaner - at the end we will have to extract images from the multiresolution image to repack them into different multiresolution image because the base size of the image will not be the same and it does matter in how they will be scaled on the different screens. And we still need to extract both images because sometimes small resolution image looks not like the large resolution one and for a reason - so small resolution image is not blurred by the small detail on the large icon when scaling on the low resolution screen. > > No, I can't see how it's relevant. If the scale factor is 100% and the requested icon size is 16, then 16?16 is used; if the window is moved to a monitor with scale factor 200%, then 32?32 icon is used for rendering which is already fetched and available in the multi-resolution image ? perfect, there's the benefit. > > But when is it possible that the scale factor is less than 100%? > > If `JFileChooser` requests a large icon that is 32?32, then it will be used for rendering when the scale factor is 100%. When the scale factor is 200%, the icon of 64?64 is required but it's not available, instead there's 16?16 icon. For this icon to be used, the scale factor needs to be 50%. Ok, changed so only the icons that are higher or same size as requested will be in the resulting set (unless size requested exceeds the maximum allowed quality, in this case only maximum quality variant will be provided). ------------- PR: https://git.openjdk.java.net/jdk/pull/2875 From kizune at openjdk.java.net Sat May 8 00:19:21 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Sat, 8 May 2021 00:19:21 GMT Subject: RFR: 8182043: Access to Windows Large Icons [v4] In-Reply-To: References: Message-ID: > Fix updated after first round of review. Alexander Zuev 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: - Small fixes Added testing for MultiResolutionImage - Merge remote-tracking branch 'origin/master' into JDK-8182043 - Update src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp Select one icon at a time. Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> - Small fixes Remived size parameter from makeIcon Removed useVGAColors usage as irrelevant since it is ignored on all supported platforms now - 8182043: Access to Windows Large Icons Fix updated based on the previous review. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2875/files - new: https://git.openjdk.java.net/jdk/pull/2875/files/4a360621..237d4070 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2875&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2875&range=02-03 Stats: 709331 lines in 9669 files changed: 139154 ins; 543848 del; 26329 mod Patch: https://git.openjdk.java.net/jdk/pull/2875.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2875/head:pull/2875 PR: https://git.openjdk.java.net/jdk/pull/2875 From kizune at openjdk.java.net Sat May 8 00:19:24 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Sat, 8 May 2021 00:19:24 GMT Subject: RFR: 8182043: Access to Windows Large Icons [v4] In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 20:50:53 GMT, Alexey Ivanov wrote: >> test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java line 64: >> >>> 62: } >>> 63: >>> 64: if (icon.getIconWidth() != size) { >> >> Does it make sense to check that the icon is a multi-resolution image with the expected sizes? >> We know for sure `explorer.exe` contains the entire set of icons. > > Since the test always expects a multi-resolution image, does it make sense to assert `icon instanceof MultiResolutionImage` at the very least? Ok, added testing for multiresolution icon. ------------- PR: https://git.openjdk.java.net/jdk/pull/2875 From psadhukhan at openjdk.java.net Sat May 8 04:38:03 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Sat, 8 May 2021 04:38:03 GMT Subject: RFR: 8265528: Specification of BasicSplitPaneDivider::getMinimumSize, getPreferredSize doesn't match with its behavior. [v3] In-Reply-To: References: Message-ID: > The current specification of these 2 methods > api/java.desktop/javax/swing/plaf/basic/BasicSplitPaneDivider.html#getPreferredSize(). > and > api/java.desktop/javax/swing/plaf/basic/BasicSplitPaneDivider.html#getMinimumSize() > does not specify correct return values. Also, the spec is not very intuitive and clear. > > Rectified the spec to specify correct behaviour. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Spec wording correction ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3870/files - new: https://git.openjdk.java.net/jdk/pull/3870/files/eea67529..5e1a55cd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3870&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3870&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3870.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3870/head:pull/3870 PR: https://git.openjdk.java.net/jdk/pull/3870 From kizune at openjdk.java.net Sat May 8 05:28:39 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Sat, 8 May 2021 05:28:39 GMT Subject: RFR: 8266249: javax/swing/JPopupMenu/7156657/bug7156657.java fails on macOS [v3] In-Reply-To: References: Message-ID: <2fcAOQfVZhAmdz5za8MszxeUzFCD8urHVn4MWnOIW7g=.2cbb05bc-8a91-4be4-9cba-028ce6e8b8dc@github.com> > Fixed popup position taking into account its offset > Added a lot of screenshots taking to better understand failures should they happen down the line Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Simplify popup bounds calculation ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3844/files - new: https://git.openjdk.java.net/jdk/pull/3844/files/f3589c68..3a87c08b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3844&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3844&range=01-02 Stats: 7 lines in 1 file changed: 0 ins; 5 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3844.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3844/head:pull/3844 PR: https://git.openjdk.java.net/jdk/pull/3844 From psadhukhan at openjdk.java.net Sat May 8 06:47:15 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Sat, 8 May 2021 06:47:15 GMT Subject: RFR: 8266249: javax/swing/JPopupMenu/7156657/bug7156657.java fails on macOS [v2] In-Reply-To: References: <513ojy1NZgCCFnfgG93zQT3W0x3RgvZcAkzKmQQLI3U=.9ab34682-3d9e-464e-b71e-cdffdf22aa9b@github.com> Message-ID: On Fri, 7 May 2021 20:53:08 GMT, Alexander Zuev wrote: > > > > I'm not sure about this change...Maybe changing frame location from (0,0) at l192 to middle of screen though selLocationRelativeTo() may be enough to make the test more stable in CI systems. > > The problem here is not only in location but in the screenshot taking area outside of the popup and analyzing it. That is one of the reasons why test is unreliable - it analyzes the wrong place. And moving frame to the different position will not help either - the problem is not that system menubar overlaps the popup - it does not, the problem is that we are catching part of the menubar because we do not adjust for the offset it introduces to the screen coordinates. Here's the screenshot, note that area we are analyzing is one outlined with cyan borders. By not adjusting the location we just catching random stuff. > ![dev0scr0](https://user-images.githubusercontent.com/69642324/117507970-acfb9700-af3c-11eb-8791-a1fe62e140a9.png) OK...I will still urge to bring the frame to middle to be more safe. BTW, greenFrame and redFrame screencapture are needed only in failure case so I guess those should be called if compare fails. Also, dispose should be called in EDT same way we are doing a little bit afterwards.. ------------- PR: https://git.openjdk.java.net/jdk/pull/3844 From pbansal at openjdk.java.net Sat May 8 11:00:05 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Sat, 8 May 2021 11:00:05 GMT Subject: Integrated: 8265291: Error in Javadoc for doAccessibleAction API in AccessibleJSlider class In-Reply-To: References: Message-ID: On Sun, 2 May 2021 06:09:23 GMT, Pankaj Bansal wrote: > There is a small error in javadoc for doAccessibleAction function added in AccessibleJSlider class under JDK-8262981. The documentation says that the API returns true always, whereas it can return both true or false depending upon the parameter value, same as is the case with same API in AccessibleJSpinner. This error happened do to an oversight and current fix corrects the error. This pull request has now been integrated. Changeset: 3af4efdf Author: Pankaj Bansal URL: https://git.openjdk.java.net/jdk/commit/3af4efdfcfbbb52d38415374083c66c9e7b22604 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8265291: Error in Javadoc for doAccessibleAction API in AccessibleJSlider class Reviewed-by: azvegint, jdv ------------- PR: https://git.openjdk.java.net/jdk/pull/3832 From kizune at openjdk.java.net Sat May 8 16:01:28 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Sat, 8 May 2021 16:01:28 GMT Subject: RFR: 8266249: javax/swing/JPopupMenu/7156657/bug7156657.java fails on macOS [v4] In-Reply-To: References: Message-ID: > Fixed popup position taking into account its offset > Added a lot of screenshots taking to better understand failures should they happen down the line Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Small fixes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3844/files - new: https://git.openjdk.java.net/jdk/pull/3844/files/3a87c08b..7575b1c9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3844&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3844&range=02-03 Stats: 6 lines in 1 file changed: 3 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3844.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3844/head:pull/3844 PR: https://git.openjdk.java.net/jdk/pull/3844 From pbansal at openjdk.java.net Sat May 8 16:07:01 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Sat, 8 May 2021 16:07:01 GMT Subject: RFR: 8266249: javax/swing/JPopupMenu/7156657/bug7156657.java fails on macOS [v4] In-Reply-To: References: Message-ID: <7q_Sni4fKLII1Wos0oPl-J-44dljPe8nXQjjNnUzqZs=.e18a8570-597c-419d-9364-495ff024f162@github.com> On Sat, 8 May 2021 16:01:28 GMT, Alexander Zuev wrote: >> Fixed popup position taking into account its offset >> Added a lot of screenshots taking to better understand failures should they happen down the line > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Small fixes Marked as reviewed by pbansal (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3844 From kizune at openjdk.java.net Sat May 8 16:07:01 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Sat, 8 May 2021 16:07:01 GMT Subject: RFR: 8266249: javax/swing/JPopupMenu/7156657/bug7156657.java fails on macOS [v2] In-Reply-To: References: <513ojy1NZgCCFnfgG93zQT3W0x3RgvZcAkzKmQQLI3U=.9ab34682-3d9e-464e-b71e-cdffdf22aa9b@github.com> Message-ID: On Sat, 8 May 2021 06:43:44 GMT, Prasanta Sadhukhan wrote: > I will still urge to bring the frame to middle to be more safe. Ok, not that it makes any difference so there you go. > BTW, greenFrame and redFrame screencapture are needed only in failure case so I guess those should be called if compare fails. Well, when comparison fails it is kind of too late to get "Before" and "After" screenshots, because "Before" is no longer there and "After" can also not be the same. And i'm saving these screenshots only if comparison fails so the performance impact is negligible. > Also, dispose should be called in EDT same way we are doing a little bit afterwards.. Ok, fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3844 From azvegint at openjdk.java.net Sat May 8 21:10:07 2021 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Sat, 8 May 2021 21:10:07 GMT Subject: RFR: 8266249: javax/swing/JPopupMenu/7156657/bug7156657.java fails on macOS [v4] In-Reply-To: References: Message-ID: On Sat, 8 May 2021 16:01:28 GMT, Alexander Zuev wrote: >> Fixed popup position taking into account its offset >> Added a lot of screenshots taking to better understand failures should they happen down the line > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Small fixes Marked as reviewed by azvegint (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3844 From kizune at openjdk.java.net Mon May 10 03:27:06 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Mon, 10 May 2021 03:27:06 GMT Subject: Integrated: 8266249: javax/swing/JPopupMenu/7156657/bug7156657.java fails on macOS In-Reply-To: References: Message-ID: <3P8Qmzrdb381jBtYOS2cYNhy2jHkFAA2Gsouwf6KXvs=.6efe4190-e6c0-4ce3-a969-805058d95747@github.com> On Mon, 3 May 2021 19:30:07 GMT, Alexander Zuev wrote: > Fixed popup position taking into account its offset > Added a lot of screenshots taking to better understand failures should they happen down the line This pull request has now been integrated. Changeset: 9b769550 Author: Alexander Zuev URL: https://git.openjdk.java.net/jdk/commit/9b769550242e8bf6f9e783bf0d6f4a87d0c6376d Stats: 41 lines in 1 file changed: 39 ins; 1 del; 1 mod 8266249: javax/swing/JPopupMenu/7156657/bug7156657.java fails on macOS Reviewed-by: jdv, pbansal, azvegint ------------- PR: https://git.openjdk.java.net/jdk/pull/3844 From serb at openjdk.java.net Mon May 10 21:51:03 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 10 May 2021 21:51:03 GMT Subject: RFR: 8266249: javax/swing/JPopupMenu/7156657/bug7156657.java fails on macOS [v4] In-Reply-To: References: Message-ID: On Sat, 8 May 2021 16:01:28 GMT, Alexander Zuev wrote: >> Fixed popup position taking into account its offset >> Added a lot of screenshots taking to better understand failures should they happen down the line > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Small fixes test/jdk/javax/swing/JPopupMenu/7156657/bug7156657.java line 113: > 111: public Rectangle call() throws Exception { > 112: return new Rectangle(popupMenu.getLocationOnScreen(), > 113: popupMenu.getSize()); Does it mean that the getBounds method returns the wrong coordinate? ------------- PR: https://git.openjdk.java.net/jdk/pull/3844 From kizune at openjdk.java.net Tue May 11 04:21:56 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Tue, 11 May 2021 04:21:56 GMT Subject: RFR: 8266249: javax/swing/JPopupMenu/7156657/bug7156657.java fails on macOS [v4] In-Reply-To: References: Message-ID: <1FKI-JjeW77ulYPQLN5il3nEyUsR0pttijQCinrZBH0=.2508522b-affe-4b0a-abe7-8e631f0fc936@github.com> On Mon, 10 May 2021 21:47:31 GMT, Sergey Bylokhov wrote: >> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: >> >> Small fixes > > test/jdk/javax/swing/JPopupMenu/7156657/bug7156657.java line 113: > >> 111: public Rectangle call() throws Exception { >> 112: return new Rectangle(popupMenu.getLocationOnScreen(), >> 113: popupMenu.getSize()); > > Does it mean that the getBounds method returns the wrong coordinate? As per documentation - it returns coordinates related to the parent. Parent was a frameless window that we asked to go to 0,0 which means that parent coordinates == screen coordinates. With one exception - on Mac OS the menu bar is on the top and the window got shifted by the insets introduced by it. So, yes, in this case coordinates were incorrect. Or rather we used the wrong method to retrieve them. ------------- PR: https://git.openjdk.java.net/jdk/pull/3844 From aivanov at openjdk.java.net Tue May 11 10:17:10 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 11 May 2021 10:17:10 GMT Subject: RFR: 8182043: Access to Windows Large Icons [v4] In-Reply-To: References: Message-ID: <2zirz4WwidWs_dg-RpslMezwpGPNvU7_7KvDTEMWLzM=.9b647b47-18d6-4a22-8237-de036fe113da@github.com> On Sat, 8 May 2021 00:19:21 GMT, Alexander Zuev wrote: >> Fix updated after first round of review. > > Alexander Zuev 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: > > - Small fixes > Added testing for MultiResolutionImage > - Merge remote-tracking branch 'origin/master' into JDK-8182043 > - Update src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp > > Select one icon at a time. > > Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> > - Small fixes > Remived size parameter from makeIcon > Removed useVGAColors usage as irrelevant since it is ignored on all > supported platforms now > - 8182043: Access to Windows Large Icons > Fix updated based on the previous review. src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 267: > 265: * returned will be a multi-resolution icon image, > 266: * which will allow better scaling with different > 267: * scaling factors. ??which will allow better support for High DPI environments with different scaling factors.? ? does it look better? ?scaling with ? scaling factors? doesn't sound good to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/2875 From aivanov at openjdk.java.net Tue May 11 10:19:56 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 11 May 2021 10:19:56 GMT Subject: RFR: 8182043: Access to Windows Large Icons [v3] In-Reply-To: References: <3hQNodTn6s3lrpoRv7bTa-fDV4OBwdEiHiV_vo3zJQY=.f5f64501-eb98-4ffa-83b1-b3841abf290b@github.com> Message-ID: On Fri, 7 May 2021 17:30:15 GMT, Alexander Zuev wrote: >> src/java.desktop/share/classes/sun/awt/shell/ShellFolder.java line 213: >> >>> 211: * Returns the icon of the specified size used to display this shell folder. >>> 212: * >>> 213: * @param size size of the icon > 0 (Valid range: 1 to 256) >> >> I'm unsure the valid range of 1 to 256 makes sense provided the icon smaller than 16?16 is never returned (on Windows at least). > > Well, user still can request 1x1 icon - we will return the multiresolution image with minimal (1x1) icon inside that will be scaled every time the actual painting occurs. The size will define the layout of the component with the icon and can be auto-generated from the user code so i do not see why we should limit the lowest requested size - especially in the shared instance that not only specific for Windows platform. Even though 1?1 icon doesn't make much sense, you're right imposing a limitation is no good either. ------------- PR: https://git.openjdk.java.net/jdk/pull/2875 From aivanov at openjdk.java.net Tue May 11 11:07:51 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 11 May 2021 11:07:51 GMT Subject: RFR: 8182043: Access to Windows Large Icons [v4] In-Reply-To: References: Message-ID: On Sat, 8 May 2021 00:19:21 GMT, Alexander Zuev wrote: >> Fix updated after first round of review. > > Alexander Zuev 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: > > - Small fixes > Added testing for MultiResolutionImage > - Merge remote-tracking branch 'origin/master' into JDK-8182043 > - Update src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp > > Select one icon at a time. > > Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> > - Small fixes > Remived size parameter from makeIcon > Removed useVGAColors usage as irrelevant since it is ignored on all > supported platforms now > - 8182043: Access to Windows Large Icons > Fix updated based on the previous review. Changes requested by aivanov (Reviewer). src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1098: > 1096: imageCache = getLargeIcon ? smallSystemImages : largeSystemImages; > 1097: } > 1098: newIcon2 = imageCache.get(Integer.valueOf(index)); Probably, explicit boxing is unnecessary. src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1192: > 1190: */ > 1191: static Image getShell32Icon(int iconID, int size) { > 1192: long hIcon = getIconResource("shell32.dll", iconID, size, size); It's outside the scope for this code review but still, should `getIconResource` free the loaded library? With each call, the library gets loaded but it's never freed and thus it's never unloaded even if it's not needed any more. src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1196: > 1194: Image icon = makeIcon(hIcon); > 1195: disposeIcon(hIcon); > 1196: return icon; Shall it not be wrapped into multi-resolution image if the `size` is different from the actual size of the icon? Previously, it was inside `makeIcon`. src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp line 929: > 927: } > 928: HRESULT hres; > 929: IExtractIconW* pIcon; `pIcon->Release()` must be called before returning as done in `extractIcon`. ------------- PR: https://git.openjdk.java.net/jdk/pull/2875 From kizune at openjdk.java.net Tue May 11 18:53:14 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Tue, 11 May 2021 18:53:14 GMT Subject: RFR: 8182043: Access to Windows Large Icons [v4] In-Reply-To: References: Message-ID: <5sBogMQMNB4YHfJY2h_MeWExq1GsRT5tvfcIL3JlkkU=.def94ef7-9e0b-4378-9b50-b80a115a75c4@github.com> On Tue, 11 May 2021 10:53:06 GMT, Alexey Ivanov wrote: >> Alexander Zuev 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: >> >> - Small fixes >> Added testing for MultiResolutionImage >> - Merge remote-tracking branch 'origin/master' into JDK-8182043 >> - Update src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp >> >> Select one icon at a time. >> >> Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> >> - Small fixes >> Remived size parameter from makeIcon >> Removed useVGAColors usage as irrelevant since it is ignored on all >> supported platforms now >> - 8182043: Access to Windows Large Icons >> Fix updated based on the previous review. > > src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1192: > >> 1190: */ >> 1191: static Image getShell32Icon(int iconID, int size) { >> 1192: long hIcon = getIconResource("shell32.dll", iconID, size, size); > > It's outside the scope for this code review but still, should `getIconResource` free the loaded library? With each call, the library gets loaded but it's never freed and thus it's never unloaded even if it's not needed any more. I will create a separate bug to track this - i do not know if library loading gets cached on some level and what impact on performance will we have if we release it every call. But i will check it out separately. > src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1196: > >> 1194: Image icon = makeIcon(hIcon); >> 1195: disposeIcon(hIcon); >> 1196: return icon; > > Shall it not be wrapped into multi-resolution image if the `size` is different from the actual size of the icon? > Previously, it was inside `makeIcon`. Wherever it is necessary down the line we are wrapping the result in multi-resolution and if we wrap it here too we will have multi-resolution icon that contains multi-resolution images as a resolution variant. Unfortunately AWT can't handle painting of such abomination. ------------- PR: https://git.openjdk.java.net/jdk/pull/2875 From aivanov at openjdk.java.net Tue May 11 19:39:24 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 11 May 2021 19:39:24 GMT Subject: RFR: 8182043: Access to Windows Large Icons [v4] In-Reply-To: <5sBogMQMNB4YHfJY2h_MeWExq1GsRT5tvfcIL3JlkkU=.def94ef7-9e0b-4378-9b50-b80a115a75c4@github.com> References: <5sBogMQMNB4YHfJY2h_MeWExq1GsRT5tvfcIL3JlkkU=.def94ef7-9e0b-4378-9b50-b80a115a75c4@github.com> Message-ID: On Tue, 11 May 2021 18:50:13 GMT, Alexander Zuev wrote: >> src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1192: >> >>> 1190: */ >>> 1191: static Image getShell32Icon(int iconID, int size) { >>> 1192: long hIcon = getIconResource("shell32.dll", iconID, size, size); >> >> It's outside the scope for this code review but still, should `getIconResource` free the loaded library? With each call, the library gets loaded but it's never freed and thus it's never unloaded even if it's not needed any more. > > I will create a separate bug to track this - i do not know if library loading gets cached on some level and what impact on performance will we have if we release it every call. But i will check it out separately. Sure! I just wanted to bring it up. I could've submitted the bug myself? yet I decided to ask at first. As far as I can see `JDK_LoadSystemLibrary` has no caching, it just loads the library. If any icons are accessed `shell32.dll` will already be loaded. Probably, we never fully release it from COM. So in this case, loading and freeing will just increase and decrease the counters. Even if it's never really unloaded, we should release the resources that's not needed any more. ------------- PR: https://git.openjdk.java.net/jdk/pull/2875 From aivanov at openjdk.java.net Tue May 11 20:05:05 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 11 May 2021 20:05:05 GMT Subject: RFR: 8182043: Access to Windows Large Icons [v4] In-Reply-To: <5sBogMQMNB4YHfJY2h_MeWExq1GsRT5tvfcIL3JlkkU=.def94ef7-9e0b-4378-9b50-b80a115a75c4@github.com> References: <5sBogMQMNB4YHfJY2h_MeWExq1GsRT5tvfcIL3JlkkU=.def94ef7-9e0b-4378-9b50-b80a115a75c4@github.com> Message-ID: On Tue, 11 May 2021 18:48:31 GMT, Alexander Zuev wrote: >> src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1196: >> >>> 1194: Image icon = makeIcon(hIcon); >>> 1195: disposeIcon(hIcon); >>> 1196: return icon; >> >> Shall it not be wrapped into multi-resolution image if the `size` is different from the actual size of the icon? >> Previously, it was inside `makeIcon`. > > Wherever it is necessary down the line we are wrapping the result in multi-resolution and if we wrap it here too we will have multi-resolution icon that contains multi-resolution images as a resolution variant. Unfortunately AWT can't handle painting of such abomination. No, it isn't wrapped: if `getShell32Icon` is called in `getIcon(final boolean getLargeIcon)`, the returned value is immediately returned to the caller, see lines 1157?1163 in the updated code: if (hIcon <= 0) { if (isDirectory()) { return getShell32Icon(FOLDER_ICON_ID, size); } else { return getShell32Icon(FILE_ICON_ID, size); } } It's not wrapped into multi-resolution icon when called from `Win32ShellFolder2.get()` for keys `shell32Icon *` and `shell32LargeIcon *` (lines 411/413?414). Neither is the returned value of `Win32ShellFolder2.getSystemIcon` wrapped; it's also called from `Win32ShellFolder2.get()` when getting icons for `optionPaneIcon *` (lines 405/407). These icons are supposed to be large 32?32 icons, thus if the size of the icon in `getSystemIcon(SystemIcon iconType)` differs from 32, it should be wrapped. Otherwise, it could cause regression for [JDK-8151385](https://bugs.openjdk.java.net/browse/JDK-8151385): _[hidpi] JOptionPane-Icons only partially visible when using Windows 10 L&F_. ------------- PR: https://git.openjdk.java.net/jdk/pull/2875 From kizune at openjdk.java.net Tue May 11 20:22:01 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Tue, 11 May 2021 20:22:01 GMT Subject: RFR: 8182043: Access to Windows Large Icons [v4] In-Reply-To: <2zirz4WwidWs_dg-RpslMezwpGPNvU7_7KvDTEMWLzM=.9b647b47-18d6-4a22-8237-de036fe113da@github.com> References: <2zirz4WwidWs_dg-RpslMezwpGPNvU7_7KvDTEMWLzM=.9b647b47-18d6-4a22-8237-de036fe113da@github.com> Message-ID: On Tue, 11 May 2021 10:07:30 GMT, Alexey Ivanov wrote: >> Alexander Zuev 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: >> >> - Small fixes >> Added testing for MultiResolutionImage >> - Merge remote-tracking branch 'origin/master' into JDK-8182043 >> - Update src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp >> >> Select one icon at a time. >> >> Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> >> - Small fixes >> Remived size parameter from makeIcon >> Removed useVGAColors usage as irrelevant since it is ignored on all >> supported platforms now >> - 8182043: Access to Windows Large Icons >> Fix updated based on the previous review. > > src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 267: > >> 265: * returned will be a multi-resolution icon image, >> 266: * which will allow better scaling with different >> 267: * scaling factors. > > ??which will allow better support for High DPI environments with different scaling factors.? ? does it look better? > ?scaling with ? scaling factors? doesn't sound good to me. Yes, much better. I updated the wording and once the PR is approved i will fix it in CSR too. > src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1098: > >> 1096: imageCache = getLargeIcon ? smallSystemImages : largeSystemImages; >> 1097: } >> 1098: newIcon2 = imageCache.get(Integer.valueOf(index)); > > Probably, explicit boxing is unnecessary. Removed. > src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp line 929: > >> 927: } >> 928: HRESULT hres; >> 929: IExtractIconW* pIcon; > > `pIcon->Release()` must be called before returning as done in `extractIcon`. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/2875 From kizune at openjdk.java.net Tue May 11 20:21:50 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Tue, 11 May 2021 20:21:50 GMT Subject: RFR: 8182043: Access to Windows Large Icons [v5] In-Reply-To: References: Message-ID: > Fix updated after first round of review. Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Slightly changing javadoc wording Removing unnecessary boxing of int Releasing the pIcon in native code properly ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2875/files - new: https://git.openjdk.java.net/jdk/pull/2875/files/237d4070..a481b29b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2875&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2875&range=03-04 Stats: 6 lines in 3 files changed: 3 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2875.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2875/head:pull/2875 PR: https://git.openjdk.java.net/jdk/pull/2875 From kizune at openjdk.java.net Tue May 11 21:41:16 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Tue, 11 May 2021 21:41:16 GMT Subject: RFR: 8182043: Access to Windows Large Icons [v4] In-Reply-To: References: <5sBogMQMNB4YHfJY2h_MeWExq1GsRT5tvfcIL3JlkkU=.def94ef7-9e0b-4378-9b50-b80a115a75c4@github.com> Message-ID: <0oEgn3O_wW8CJnEMIndoKXjhG2XhMqTcbSWOeZSWfuI=.56f01743-a8a1-4b7f-87bc-936b13908b1a@github.com> On Tue, 11 May 2021 20:01:37 GMT, Alexey Ivanov wrote: >> Wherever it is necessary down the line we are wrapping the result in multi-resolution and if we wrap it here too we will have multi-resolution icon that contains multi-resolution images as a resolution variant. Unfortunately AWT can't handle painting of such abomination. > > No, it isn't wrapped: if `getShell32Icon` is called in `getIcon(final boolean getLargeIcon)`, the returned value is immediately returned to the caller, see lines 1157?1163 in the updated code: > > if (hIcon <= 0) { > if (isDirectory()) { > return getShell32Icon(FOLDER_ICON_ID, size); > } else { > return getShell32Icon(FILE_ICON_ID, size); > } > } > > It's not wrapped into multi-resolution icon when called from `Win32ShellFolder2.get()` for keys `shell32Icon *` and `shell32LargeIcon *` (lines 411/413?414). > > Neither is the returned value of `Win32ShellFolder2.getSystemIcon` wrapped; it's also called from `Win32ShellFolder2.get()` when getting icons for `optionPaneIcon *` (lines 405/407). These icons are supposed to be large 32?32 icons, thus if the size of the icon in `getSystemIcon(SystemIcon iconType)` differs from 32, it should be wrapped. Otherwise, it could cause regression for [JDK-8151385](https://bugs.openjdk.java.net/browse/JDK-8151385): _[hidpi] JOptionPane-Icons only partially visible when using Windows 10 L&F_. I see - but still it has to be solved in the getShell32Icon method - which i'm going to do in a moment. ------------- PR: https://git.openjdk.java.net/jdk/pull/2875 From kizune at openjdk.java.net Tue May 11 21:41:15 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Tue, 11 May 2021 21:41:15 GMT Subject: RFR: 8182043: Access to Windows Large Icons [v6] In-Reply-To: References: Message-ID: > Fix updated after first round of review. Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Make getShell32Icon method return multi-resolition image in case of requested icon size and actual icon size mismatch. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2875/files - new: https://git.openjdk.java.net/jdk/pull/2875/files/a481b29b..10bae9be Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2875&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2875&range=04-05 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2875.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2875/head:pull/2875 PR: https://git.openjdk.java.net/jdk/pull/2875 From psadhukhan at openjdk.java.net Wed May 12 05:53:21 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 12 May 2021 05:53:21 GMT Subject: RFR: 8265528: Specification of BasicSplitPaneDivider::getMinimumSize, getPreferredSize doesn't match with its behavior. [v4] In-Reply-To: References: Message-ID: > The current specification of these 2 methods > api/java.desktop/javax/swing/plaf/basic/BasicSplitPaneDivider.html#getPreferredSize(). > and > api/java.desktop/javax/swing/plaf/basic/BasicSplitPaneDivider.html#getMinimumSize() > does not specify correct return values. Also, the spec is not very intuitive and clear. > > Rectified the spec to specify correct behaviour. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Change to @implNote as per CSR notes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3870/files - new: https://git.openjdk.java.net/jdk/pull/3870/files/5e1a55cd..4fcc1ea1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3870&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3870&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3870.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3870/head:pull/3870 PR: https://git.openjdk.java.net/jdk/pull/3870 From psadhukhan at openjdk.java.net Thu May 13 04:45:56 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 13 May 2021 04:45:56 GMT Subject: Integrated: 8265528: Specification of BasicSplitPaneDivider::getMinimumSize, getPreferredSize doesn't match with its behavior. In-Reply-To: References: Message-ID: On Wed, 5 May 2021 07:01:34 GMT, Prasanta Sadhukhan wrote: > The current specification of these 2 methods > api/java.desktop/javax/swing/plaf/basic/BasicSplitPaneDivider.html#getPreferredSize(). > and > api/java.desktop/javax/swing/plaf/basic/BasicSplitPaneDivider.html#getMinimumSize() > does not specify correct return values. Also, the spec is not very intuitive and clear. > > Rectified the spec to specify correct behaviour. This pull request has now been integrated. Changeset: b50fc5f9 Author: Prasanta Sadhukhan URL: https://git.openjdk.java.net/jdk/commit/b50fc5f992c2a1bdcdc8cae4aacf2a16598d5d05 Stats: 19 lines in 1 file changed: 16 ins; 0 del; 3 mod 8265528: Specification of BasicSplitPaneDivider::getMinimumSize,getPreferredSize doesn't match with its behavior. Reviewed-by: kizune ------------- PR: https://git.openjdk.java.net/jdk/pull/3870 From aivanov at openjdk.java.net Fri May 14 13:40:38 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Fri, 14 May 2021 13:40:38 GMT Subject: RFR: 8182043: Access to Windows Large Icons [v4] In-Reply-To: References: <5sBogMQMNB4YHfJY2h_MeWExq1GsRT5tvfcIL3JlkkU=.def94ef7-9e0b-4378-9b50-b80a115a75c4@github.com> Message-ID: On Tue, 11 May 2021 19:36:12 GMT, Alexey Ivanov wrote: >> I will create a separate bug to track this - i do not know if library loading gets cached on some level and what impact on performance will we have if we release it every call. But i will check it out separately. > > Sure! I just wanted to bring it up. I could've submitted the bug myself? yet I decided to ask at first. > As far as I can see `JDK_LoadSystemLibrary` has no caching, it just loads the library. If any icons are accessed `shell32.dll` will already be loaded. Probably, we never fully release it from COM. So in this case, loading and freeing will just increase and decrease the counters. Even if it's never really unloaded, we should release the resources that's not needed any more. For documentation purposes, [JDK-8266948](https://bugs.openjdk.java.net/browse/JDK-8266948): ShellFolder2::getIconResource does not release the library loaded. ------------- PR: https://git.openjdk.java.net/jdk/pull/2875 From aivanov at openjdk.java.net Fri May 14 13:40:38 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Fri, 14 May 2021 13:40:38 GMT Subject: RFR: 8182043: Access to Windows Large Icons [v6] In-Reply-To: References: Message-ID: On Tue, 11 May 2021 21:41:15 GMT, Alexander Zuev wrote: >> Fix updated after first round of review. > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Make getShell32Icon method return multi-resolition image in case of > requested icon size and actual icon size mismatch. Changes requested by aivanov (Reviewer). src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 266: > 264: * {@code ShellFolder} class. Whenever possible, the icon > 265: * returned will be a multi-resolution icon image, > 266: * which will allow better support for High DPI environments I'm not sure but probably ??which allows better?? is more grammatical, as well as in the line above: ?the icon returned is a multi-resolution?. Phil or Joe could correct this. ------------- PR: https://git.openjdk.java.net/jdk/pull/2875 From aivanov at openjdk.java.net Fri May 14 13:44:38 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Fri, 14 May 2021 13:44:38 GMT Subject: RFR: 8182043: Access to Windows Large Icons [v4] In-Reply-To: <0oEgn3O_wW8CJnEMIndoKXjhG2XhMqTcbSWOeZSWfuI=.56f01743-a8a1-4b7f-87bc-936b13908b1a@github.com> References: <5sBogMQMNB4YHfJY2h_MeWExq1GsRT5tvfcIL3JlkkU=.def94ef7-9e0b-4378-9b50-b80a115a75c4@github.com> <0oEgn3O_wW8CJnEMIndoKXjhG2XhMqTcbSWOeZSWfuI=.56f01743-a8a1-4b7f-87bc-936b13908b1a@github.com> Message-ID: <6GDDDBPRIUi9NBAdTnlmzfs6Uf-Mh6vaNFRkzsHnbrY=.b4c9cf43-2aca-4fb4-96d6-1b4530cd4634@github.com> On Tue, 11 May 2021 21:34:59 GMT, Alexander Zuev wrote: >> No, it isn't wrapped: if `getShell32Icon` is called in `getIcon(final boolean getLargeIcon)`, the returned value is immediately returned to the caller, see lines 1157?1163 in the updated code: >> >> if (hIcon <= 0) { >> if (isDirectory()) { >> return getShell32Icon(FOLDER_ICON_ID, size); >> } else { >> return getShell32Icon(FILE_ICON_ID, size); >> } >> } >> >> It's not wrapped into multi-resolution icon when called from `Win32ShellFolder2.get()` for keys `shell32Icon *` and `shell32LargeIcon *` (lines 411/413?414). >> >> Neither is the returned value of `Win32ShellFolder2.getSystemIcon` wrapped; it's also called from `Win32ShellFolder2.get()` when getting icons for `optionPaneIcon *` (lines 405/407). These icons are supposed to be large 32?32 icons, thus if the size of the icon in `getSystemIcon(SystemIcon iconType)` differs from 32, it should be wrapped. Otherwise, it could cause regression for [JDK-8151385](https://bugs.openjdk.java.net/browse/JDK-8151385): _[hidpi] JOptionPane-Icons only partially visible when using Windows 10 L&F_. > > I see - but still it has to be solved in the getShell32Icon method - which i'm going to do in a moment. `Win32ShellFolder2.getSystemIcon` is still affected, the return value should be wrapped into MR-icon if its size is not equal to `LARGE_ICON_SIZE`. static Image getSystemIcon(SystemIcon iconType) { long hIcon = getSystemIcon(iconType.getIconID()); Image icon = makeIcon(hIcon); if (LARGE_ICON_SIZE != icon.getWidth(null)) { icon = new MultiResolutionIconImage(size, icon); } disposeIcon(hIcon); return icon; } ------------- PR: https://git.openjdk.java.net/jdk/pull/2875 From kizune at openjdk.java.net Fri May 14 18:47:42 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Fri, 14 May 2021 18:47:42 GMT Subject: RFR: 8182043: Access to Windows Large Icons [v6] In-Reply-To: References: Message-ID: On Fri, 14 May 2021 13:30:13 GMT, Alexey Ivanov wrote: >> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: >> >> Make getShell32Icon method return multi-resolition image in case of >> requested icon size and actual icon size mismatch. > > src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 266: > >> 264: * {@code ShellFolder} class. Whenever possible, the icon >> 265: * returned will be a multi-resolution icon image, >> 266: * which will allow better support for High DPI environments > > I'm not sure but probably ??which allows better?? is more grammatical, as well as in the line above: ?the icon returned is a multi-resolution?. > > Phil or Joe could correct this. Agree. ------------- PR: https://git.openjdk.java.net/jdk/pull/2875 From kizune at openjdk.java.net Fri May 14 18:47:42 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Fri, 14 May 2021 18:47:42 GMT Subject: RFR: 8182043: Access to Windows Large Icons [v4] In-Reply-To: <6GDDDBPRIUi9NBAdTnlmzfs6Uf-Mh6vaNFRkzsHnbrY=.b4c9cf43-2aca-4fb4-96d6-1b4530cd4634@github.com> References: <5sBogMQMNB4YHfJY2h_MeWExq1GsRT5tvfcIL3JlkkU=.def94ef7-9e0b-4378-9b50-b80a115a75c4@github.com> <0oEgn3O_wW8CJnEMIndoKXjhG2XhMqTcbSWOeZSWfuI=.56f01743-a8a1-4b7f-87bc-936b13908b1a@github.com> <6GDDDBPRIUi9NBAdTnlmzfs6Uf-Mh6vaNFRkzsHnbrY=.b4c9cf43-2aca-4fb4-96d6-1b4530cd4634@github.com> Message-ID: On Fri, 14 May 2021 13:41:31 GMT, Alexey Ivanov wrote: >> I see - but still it has to be solved in the getShell32Icon method - which i'm going to do in a moment. > > `Win32ShellFolder2.getSystemIcon` is still affected, the return value should be wrapped into MR-icon if its size is not equal to `LARGE_ICON_SIZE`. > > static Image getSystemIcon(SystemIcon iconType) { > long hIcon = getSystemIcon(iconType.getIconID()); > Image icon = makeIcon(hIcon); > if (LARGE_ICON_SIZE != icon.getWidth(null)) { > icon = new MultiResolutionIconImage(size, icon); > } > disposeIcon(hIcon); > return icon; > } Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/2875 From kizune at openjdk.java.net Fri May 14 19:46:03 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Fri, 14 May 2021 19:46:03 GMT Subject: RFR: 8182043: Access to Windows Large Icons [v7] In-Reply-To: References: Message-ID: > Fix updated after first round of review. Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Slight change of wording in javadoc Fixed Win32ShellFolder2.getSystemIcon scaling issue ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2875/files - new: https://git.openjdk.java.net/jdk/pull/2875/files/10bae9be..4cd5a508 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2875&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2875&range=05-06 Stats: 5 lines in 2 files changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2875.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2875/head:pull/2875 PR: https://git.openjdk.java.net/jdk/pull/2875 From aivanov at openjdk.java.net Fri May 14 20:22:42 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Fri, 14 May 2021 20:22:42 GMT Subject: RFR: 8182043: Access to Windows Large Icons [v7] In-Reply-To: References: Message-ID: On Fri, 14 May 2021 19:46:03 GMT, Alexander Zuev wrote: >> Fix updated after first round of review. > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Slight change of wording in javadoc > Fixed Win32ShellFolder2.getSystemIcon scaling issue Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2875 From psadhukhan at openjdk.java.net Sat May 15 08:44:40 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Sat, 15 May 2021 08:44:40 GMT Subject: RFR: 8264218: Public method javax.swing.JMenu.setComponentOrientation() has no spec [v5] In-Reply-To: References: <22JyhhEtdDzZ3uaobbNwCbA7rrcNYYX2Mb6G_zYBkqM=.451f59da-c2b8-4020-b4a6-ed00605305ce@github.com> <5cYHAAOWHyRD7vQ4p1k5o1zhYW32uxsCaVVMjILVFpo=.15bb8636-458b-41ad-bdf6-19d105c6bea1@github.com> <4zXvrDVbNGJT_xrWG6aDsodCfYCdQxNdNp6AEcg4dqI=.ef4a5c05-0ba0-49a5-9076-40e48ab01ccd@github.com> <18zG-1Vc7bu1SFOuPkiojVtzmVWNHxnri0upEp4iI1o=.725325ac-3266-4263-b9e5-4d4c2198b77f@github.com> <7CyTK5xhBNteEsN_T0jFdY6WU--ijSRqMG1Vw4Dd3aU=.2fcdb272-e03f-4ef7-9abd-8651b9fe45c6@github.com> Message-ID: <4teFrXcBbajqEm84Jc36bpUQX31oevQFSxKkewPfPRg=.13b2d3f3-6795-404c-b5f9-955b2fffaccf@github.com> On Thu, 8 Apr 2021 04:59:13 GMT, Sergey Bylokhov wrote: > > > > In many places, we use {@inheritdoc} [ex. https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthToolTipUI.java#L68] for same usecase!!! > > All of them are in the SynthXX classes and were added as part of moving that classes to the javax package by the JDK-6827653 in jdk7. The spec of the parent class was used in the CCC since the new functionality of these methods was not specified and was hidden. > > So you are right, it looks like the same use case as we discussed here, and if in this case the javadoc was hidden intentionally then I assume it was hidden there as well. Lets wait how the JDK-8264217 will be resolved. JDK-8264217 is closed as wont-ftx so the spec would be empty by default as it is now.....So, can we have this spec notes instead? ------------- PR: https://git.openjdk.java.net/jdk/pull/3213 From psadhukhan at openjdk.java.net Sat May 15 08:45:41 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Sat, 15 May 2021 08:45:41 GMT Subject: Withdrawn: 8160720: [TEST_BUG] javax/swing/SwingUtilities/TestBadBreak/TestBadBreak.java In-Reply-To: References: Message-ID: On Wed, 10 Feb 2021 10:33:03 GMT, Prasanta Sadhukhan wrote: > Test hardcodes bufferedimage and frame bounds so it does not capture correct size if scaling factor is used. > The solution is to always use the same uiscale=1, an updated test still can reproduce the JDK-8015085 issue without fix. Additionally, moved the frame to centre of screen for better mach5 stability. > Mach5 job running for several iterations on all platforms is ok. Link in JBS. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/2502 From azvegint at openjdk.java.net Sun May 16 19:10:44 2021 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Sun, 16 May 2021 19:10:44 GMT Subject: RFR: 8182043: Access to Windows Large Icons [v7] In-Reply-To: References: Message-ID: On Fri, 14 May 2021 19:46:03 GMT, Alexander Zuev wrote: >> Fix updated after first round of review. > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Slight change of wording in javadoc > Fixed Win32ShellFolder2.getSystemIcon scaling issue src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 271: > 269: * Example: 
> 270:     * FileSystemView fsv = FileSystemView.getFileSystemView();
> 271:     * Icon icon = fsv.getSystemIcon("application.exe", 64);

Shouldn't the first parameter be a File instance instead of String?
`Icon icon = fsv.getSystemIcon(new File("application.exe"), 64);`

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From kizune at openjdk.java.net  Mon May 17 05:13:06 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 17 May 2021 05:13:06 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v8]
In-Reply-To: 
References: 
Message-ID: 

> Fix updated after first round of review.

Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:

  Example in JavaDoc fixed

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2875/files
  - new: https://git.openjdk.java.net/jdk/pull/2875/files/4cd5a508..911bc70b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2875&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2875&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2875.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2875/head:pull/2875

PR: https://git.openjdk.java.net/jdk/pull/2875

From kizune at openjdk.java.net  Mon May 17 05:13:07 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 17 May 2021 05:13:07 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v7]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Sun, 16 May 2021 18:49:24 GMT, Alexander Zvegintsev  wrote:

>> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Slight change of wording in javadoc
>>   Fixed Win32ShellFolder2.getSystemIcon scaling issue
>
> src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 271:
> 
>> 269:     * Example: 
>> 270:     * FileSystemView fsv = FileSystemView.getFileSystemView();
>> 271:     * Icon icon = fsv.getSystemIcon("application.exe", 64);
> 
> Shouldn't the first parameter be a File instance instead of String?
> `Icon icon = fsv.getSystemIcon(new File("application.exe"), 64);`

Good catch! Yes, fixed both here and in CSR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From psadhukhan at openjdk.java.net  Mon May 17 09:13:18 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 17 May 2021 09:13:18 GMT
Subject:  RFR: 8260331:
 javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java failed with
 "ERROR: icon and imageIcon not same."
Message-ID: <2_yrGslldmrANWDYaZjgxGCsoBn8PCGTothQ2lTiZwA=.0ec9af39-f252-41ef-96ba-a53a5643e39c@github.com>

This testcase has failed intermittently in CI testing citing icon and ImageIcon images are not same.
It's been observed that the rectangle been passed to Robot.createScreenCapture was incorrect to compare the icon images but is passing because the images were not different (but the images itself was incorrect) so not reliable.

When it fails, it is seen that the icon and imageicon images captured, with height of the screenCapture which is the value of the topinset of internalFrame, is wrong and differ in some pixels at the end
`icon captureRect java.awt.Rectangle[x=715,y=366,width=500,height=5]`
The failed images look like (where one can see that there is some difference at the end of line)
icon image
![iconImage-fail](https://user-images.githubusercontent.com/43534309/118223456-f5680700-b49e-11eb-9d9e-937f8bf96fa3.png)
image icon
![imageicon-fail](https://user-images.githubusercontent.com/43534309/118223479-01ec5f80-b49f-11eb-9f5e-f5da704f71ba.png)

which is not compring the icon images actually.

Rectified screenrect to correctly compare the icons. After the fix, the images being compared are these
icon image
![iconImage-success](https://user-images.githubusercontent.com/43534309/118223532-27796900-b49f-11eb-8bfc-63a9ed7e97f8.png)
imageicon
![imageicon-success](https://user-images.githubusercontent.com/43534309/118223544-2c3e1d00-b49f-11eb-8af9-ef3a22a4f8c9.png)

Several iterations of the modified test execution is green on all platforms. Link in JBS.
I have also verified the modified test fails without 8146321 fix.

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.java.net/jdk/pull/4048/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4048&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260331
  Stats: 11 lines in 2 files changed: 4 ins; 1 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4048.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4048/head:pull/4048

PR: https://git.openjdk.java.net/jdk/pull/4048

From azvegint at openjdk.java.net  Mon May 17 10:49:41 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Mon, 17 May 2021 10:49:41 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 17 May 2021 05:13:06 GMT, Alexander Zuev  wrote:

>> Fix updated after first round of review.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Example in JavaDoc fixed

Marked as reviewed by azvegint (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From azvegint at openjdk.java.net  Mon May 17 10:54:48 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Mon, 17 May 2021 10:54:48 GMT
Subject:  RFR: 8260331:
 javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java failed with
 "ERROR: icon and imageIcon not same."
In-Reply-To: <2_yrGslldmrANWDYaZjgxGCsoBn8PCGTothQ2lTiZwA=.0ec9af39-f252-41ef-96ba-a53a5643e39c@github.com>
References: <2_yrGslldmrANWDYaZjgxGCsoBn8PCGTothQ2lTiZwA=.0ec9af39-f252-41ef-96ba-a53a5643e39c@github.com>
Message-ID: 

On Mon, 17 May 2021 09:05:06 GMT, Prasanta Sadhukhan  wrote:

> This testcase has failed intermittently in CI testing citing icon and ImageIcon images are not same.
> It's been observed that the rectangle been passed to Robot.createScreenCapture was incorrect to compare the icon images but is passing because the images were not different (but the images itself was incorrect) so not reliable.
> 
> When it fails, it is seen that the icon and imageicon images captured, with height of the screenCapture which is the value of the topinset of internalFrame, is wrong and differ in some pixels at the end
> `icon captureRect java.awt.Rectangle[x=715,y=366,width=500,height=5]`
> The failed images look like (where one can see that there is some difference at the end of line)
> icon image
> ![iconImage-fail](https://user-images.githubusercontent.com/43534309/118223456-f5680700-b49e-11eb-9d9e-937f8bf96fa3.png)
> image icon
> ![imageicon-fail](https://user-images.githubusercontent.com/43534309/118223479-01ec5f80-b49f-11eb-9f5e-f5da704f71ba.png)
> 
> which is not compring the icon images actually.
> 
> Rectified screenrect to correctly compare the icons. After the fix, the images being compared are these
> icon image
> ![iconImage-success](https://user-images.githubusercontent.com/43534309/118223532-27796900-b49f-11eb-8bfc-63a9ed7e97f8.png)
> imageicon
> ![imageicon-success](https://user-images.githubusercontent.com/43534309/118223544-2c3e1d00-b49f-11eb-8af9-ef3a22a4f8c9.png)
> 
> Several iterations of the modified test execution is green on all platforms. Link in JBS.
> I have also verified the modified test fails without 8146321 fix.

Marked as reviewed by azvegint (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4048

From psadhukhan at openjdk.java.net  Mon May 17 12:35:39 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 17 May 2021 12:35:39 GMT
Subject:  Integrated: 8260331:
 javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java failed with
 "ERROR: icon and imageIcon not same."
In-Reply-To: <2_yrGslldmrANWDYaZjgxGCsoBn8PCGTothQ2lTiZwA=.0ec9af39-f252-41ef-96ba-a53a5643e39c@github.com>
References: <2_yrGslldmrANWDYaZjgxGCsoBn8PCGTothQ2lTiZwA=.0ec9af39-f252-41ef-96ba-a53a5643e39c@github.com>
Message-ID: 

On Mon, 17 May 2021 09:05:06 GMT, Prasanta Sadhukhan  wrote:

> This testcase has failed intermittently in CI testing citing icon and ImageIcon images are not same.
> It's been observed that the rectangle been passed to Robot.createScreenCapture was incorrect to compare the icon images but is passing because the images were not different (but the images itself was incorrect) so not reliable.
> 
> When it fails, it is seen that the icon and imageicon images captured, with height of the screenCapture which is the value of the topinset of internalFrame, is wrong and differ in some pixels at the end
> `icon captureRect java.awt.Rectangle[x=715,y=366,width=500,height=5]`
> The failed images look like (where one can see that there is some difference at the end of line)
> icon image
> ![iconImage-fail](https://user-images.githubusercontent.com/43534309/118223456-f5680700-b49e-11eb-9d9e-937f8bf96fa3.png)
> image icon
> ![imageicon-fail](https://user-images.githubusercontent.com/43534309/118223479-01ec5f80-b49f-11eb-9f5e-f5da704f71ba.png)
> 
> which is not compring the icon images actually.
> 
> Rectified screenrect to correctly compare the icons. After the fix, the images being compared are these
> icon image
> ![iconImage-success](https://user-images.githubusercontent.com/43534309/118223532-27796900-b49f-11eb-8bfc-63a9ed7e97f8.png)
> imageicon
> ![imageicon-success](https://user-images.githubusercontent.com/43534309/118223544-2c3e1d00-b49f-11eb-8af9-ef3a22a4f8c9.png)
> 
> Several iterations of the modified test execution is green on all platforms. Link in JBS.
> I have also verified the modified test fails without 8146321 fix.

This pull request has now been integrated.

Changeset: 39a454bb
Author:    Prasanta Sadhukhan 
URL:       https://git.openjdk.java.net/jdk/commit/39a454bb879fe316a69a4ec33ab287db2b5837db
Stats:     11 lines in 2 files changed: 4 ins; 1 del; 6 mod

8260331: javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java failed with "ERROR: icon and imageIcon not same."

Reviewed-by: azvegint

-------------

PR: https://git.openjdk.java.net/jdk/pull/4048

From weijun at openjdk.java.net  Mon May 17 22:01:49 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 17 May 2021 22:01:49 GMT
Subject:  RFR: 8267184: JEP 411: Add
 -Djava.security.manager=allow to tests calling System.setSecurityManager
Message-ID: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>

Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).

With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).

To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas. Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:

1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.

Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.

Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.

Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.

There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).

3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).

2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:

rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
 ```

The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

-------------

Commit messages:
 - test for awt
 - test for hotspot-gc
 - test for compiler
 - test for net
 - test for core-libs
 - test for beans
 - test for xml
 - test for nio
 - test for hotspot-runtime
 - test for security
 - ... and 7 more: https://git.openjdk.java.net/jdk/compare/79b39445...900c28c0

Changes: https://git.openjdk.java.net/jdk/pull/4071/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267184
  Stats: 1024 lines in 852 files changed: 249 ins; 8 del; 767 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4071.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4071/head:pull/4071

PR: https://git.openjdk.java.net/jdk/pull/4071

From weijun at openjdk.java.net  Mon May 17 22:01:52 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 17 May 2021 22:01:52 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the Security
 Manager for Removal
Message-ID: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>

Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).

The code change is divided into 3 commits. Please review them one by one.

1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal

The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.

Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.

Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

-------------

Commit messages:
 - add supresswarnings annotations automatically
 - manual change before automatic annotating
 - 8266459: Implement JEP 411: Deprecate the Security Manager for Removal

Changes: https://git.openjdk.java.net/jdk/pull/4073/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266459
  Stats: 2018 lines in 826 files changed: 1884 ins; 9 del; 125 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Mon May 17 22:01:53 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 17 May 2021 22:01:53 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: 

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang  wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

The 3rd commit is the biggest one but it's all generated programmatically. All changes are simply adding `@SupressWarnings("removal")` to a declaration.

Precisely, of all the diff hunks (leading whitespaces ignored), there are 1607 

+ @SuppressWarnings("removal")


There are also 7 cases where an existing annotation is updated

================= 2 ====================
- @SuppressWarnings("deprecation")
+ @SuppressWarnings({"removal","deprecation"})
================= 1 ====================
- @SuppressWarnings("Convert2Lambda")
+ @SuppressWarnings({"removal","Convert2Lambda"})
================= 1 ====================
- @SuppressWarnings({"unchecked", "CloneDeclaresCloneNotSupported"})
+ @SuppressWarnings({"removal","unchecked", "CloneDeclaresCloneNotSupported"})
================= 1 ====================
- @SuppressWarnings("deprecation") // Use of RMISecurityManager
+ @SuppressWarnings({"removal","deprecation"}) // Use of RMISecurityManager
================= 1 ====================
- @SuppressWarnings("unchecked")     /*To suppress warning from line 1374*/
+ @SuppressWarnings({"removal","unchecked"})     /*To suppress warning from line 1374*/
================= 1 ====================
- @SuppressWarnings("fallthrough")
+ @SuppressWarnings({"removal","fallthrough"})


All other cases are new annotation embedded inline:

================= 7 ====================
- AccessControlContext acc) {
+ @SuppressWarnings("removal") AccessControlContext acc) {
================= 4 ====================
- AccessControlContext acc,
+ @SuppressWarnings("removal") AccessControlContext acc,
================= 3 ====================
- AccessControlContext context,
+ @SuppressWarnings("removal") AccessControlContext context,
================= 3 ====================
- AccessControlContext acc)
+ @SuppressWarnings("removal") AccessControlContext acc)
================= 2 ====================
- try (InputStream stream = AccessController.doPrivileged(pa)) {
+ try (@SuppressWarnings("removal") InputStream stream = AccessController.doPrivileged(pa)) {
================= 2 ====================
- AccessControlContext context, Permission... perms) {
+ @SuppressWarnings("removal") AccessControlContext context, Permission... perms) {
================= 2 ====================
- } catch (java.security.AccessControlException e) {
+ } catch (@SuppressWarnings("removal") java.security.AccessControlException e) {
================= 2 ====================
- } catch (AccessControlException ace) {
+ } catch (@SuppressWarnings("removal") AccessControlException ace) {
================= 2 ====================
- AccessControlContext context)
+ @SuppressWarnings("removal") AccessControlContext context)
================= 2 ====================
- AccessControlContext acc) throws LoginException {
+ @SuppressWarnings("removal") AccessControlContext acc) throws LoginException {
================= 2 ====================
- } catch (AccessControlException e) {
+ } catch (@SuppressWarnings("removal") AccessControlException e) {
================= 1 ====================
- public static void addHook(AccessControlContext acc, PlatformEventType type, Runnable hook) {
+ public static void addHook(@SuppressWarnings("removal") AccessControlContext acc, PlatformEventType type, Runnable hook) {
================= 1 ====================
- DomainCombiner combiner,
+ @SuppressWarnings("removal") DomainCombiner combiner,
================= 1 ====================
- } catch (java.security.AccessControlException ace) {
+ } catch (@SuppressWarnings("removal") java.security.AccessControlException ace) {
================= 1 ====================
- private static File checkFile(File f, SecurityManager sm) {
+ private static File checkFile(File f, @SuppressWarnings("removal") SecurityManager sm) {
================= 1 ====================
- private static File checkFile(File file, SecurityManager sm) {
+ private static File checkFile(File file, @SuppressWarnings("removal") SecurityManager sm) {
================= 1 ====================
- private static void checkPackageAccessForPermittedSubclasses(SecurityManager sm,
+ private static void checkPackageAccessForPermittedSubclasses(@SuppressWarnings("removal") SecurityManager sm,
================= 1 ====================
- ProtectionDomain[] getProtectDomains(AccessControlContext context);
+ ProtectionDomain[] getProtectDomains(@SuppressWarnings("removal") AccessControlContext context);
================= 1 ====================
- SecureCallbackHandler(java.security.AccessControlContext acc,
+ SecureCallbackHandler(@SuppressWarnings("removal") java.security.AccessControlContext acc,
================= 1 ====================
- private static void addHookInternal(AccessControlContext acc, PlatformEventType type, Runnable hook) {
+ private static void addHookInternal(@SuppressWarnings("removal") AccessControlContext acc, PlatformEventType type, Runnable hook) {
================= 1 ====================
- private void checkMemberAccess(SecurityManager sm, int which,
+ private void checkMemberAccess(@SuppressWarnings("removal") SecurityManager sm, int which,
================= 1 ====================
- private static File[] checkFiles(Stream filesStream, SecurityManager sm) {
+ private static File[] checkFiles(Stream filesStream, @SuppressWarnings("removal") SecurityManager sm) {
================= 1 ====================
- Thread(Runnable target, AccessControlContext acc) {
+ Thread(Runnable target, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- public ProtectionDomain[] getProtectDomains(AccessControlContext context) {
+ public ProtectionDomain[] getProtectDomains(@SuppressWarnings("removal") AccessControlContext context) {
================= 1 ====================
- AccessControlContext context);
+ @SuppressWarnings("removal") AccessControlContext context);
================= 1 ====================
- AccessControlContext stack,
- AccessControlContext context);
+ @SuppressWarnings("removal") AccessControlContext stack,
+ @SuppressWarnings("removal") AccessControlContext context);
================= 1 ====================
- AccessControlContext(ProtectionDomain caller, DomainCombiner combiner,
+ AccessControlContext(ProtectionDomain caller, @SuppressWarnings("removal") DomainCombiner combiner,
================= 1 ====================
- public URLClassPath(URL[] urls, AccessControlContext acc) {
+ public URLClassPath(URL[] urls, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- URLClassLoader(URL[] urls, AccessControlContext acc) {
+ URLClassLoader(URL[] urls, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- public static void setSecurityManager(SecurityManager sm) {
+ public static void setSecurityManager(@SuppressWarnings("removal") SecurityManager sm) {
================= 1 ====================
- try (DataInputStream dis = new DataInputStream(new InflaterInputStream(
+ try (@SuppressWarnings("removal") DataInputStream dis = new DataInputStream(new InflaterInputStream(
================= 1 ====================
- try (FileInputStream fis = AccessController.doPrivileged(
+ try (@SuppressWarnings("removal") FileInputStream fis = AccessController.doPrivileged(
================= 1 ====================
- FactoryURLClassLoader(URL[] urls, AccessControlContext acc) {
+ FactoryURLClassLoader(URL[] urls, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- Thread newThreadWithAcc(Runnable target, AccessControlContext acc);
+ Thread newThreadWithAcc(Runnable target, @SuppressWarnings("removal") AccessControlContext acc);
================= 1 ====================
- SecureRecorderListener(AccessControlContext context, FlightRecorderListener changeListener) {
+ SecureRecorderListener(@SuppressWarnings("removal") AccessControlContext context, FlightRecorderListener changeListener) {
================= 1 ====================
- private PolicyDelegate(PolicySpi spi, Provider p,
+ private PolicyDelegate(@SuppressWarnings("removal") PolicySpi spi, Provider p,
================= 1 ====================
- DomainCombiner combiner) {
+ @SuppressWarnings("removal") DomainCombiner combiner) {
================= 1 ====================
- PrivilegedRunnable(Runnable r, AccessControlContext acc) {
+ PrivilegedRunnable(Runnable r, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- private static File[] checkFiles(Stream fs, SecurityManager sm) {
+ private static File[] checkFiles(Stream fs, @SuppressWarnings("removal") SecurityManager sm) {
================= 1 ====================
- private void checkSpecifyHandler(SecurityManager sm) {
+ private void checkSpecifyHandler(@SuppressWarnings("removal") SecurityManager sm) {
================= 1 ====================
- String serverPrincipal, AccessControlContext acc)
+ String serverPrincipal, @SuppressWarnings("removal") AccessControlContext acc)
================= 1 ====================
- public Thread newThreadWithAcc(Runnable target, AccessControlContext acc) {
+ public Thread newThreadWithAcc(Runnable target, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- try (InputStream is = AccessController.doPrivileged(new PrivilegedAction() {
+ try (@SuppressWarnings("removal") InputStream is = AccessController.doPrivileged(new PrivilegedAction() {
================= 1 ====================
- public EventFileStream(AccessControlContext acc, Path path) throws IOException {
+ public EventFileStream(@SuppressWarnings("removal") AccessControlContext acc, Path path) throws IOException {
================= 1 ====================
- AccessControlContext context, Permission... perms)
+ @SuppressWarnings("removal") AccessControlContext context, Permission... perms)
================= 1 ====================
- private static void privateCheckPackageAccess(SecurityManager s, Class clazz) {
+ private static void privateCheckPackageAccess(@SuppressWarnings("removal") SecurityManager s, Class clazz) {
================= 1 ====================
- AbstractEventStream(AccessControlContext acc, PlatformRecording recording, List configurations) throws IOException {
+ AbstractEventStream(@SuppressWarnings("removal") AccessControlContext acc, PlatformRecording recording, List configurations) throws IOException {
================= 1 ====================
- private void checkPackageAccess(SecurityManager sm, final ClassLoader ccl,
+ private void checkPackageAccess(@SuppressWarnings("removal") SecurityManager sm, final ClassLoader ccl,
================= 1 ====================
- AccessControlContext context) {
+ @SuppressWarnings("removal") AccessControlContext context) {
================= 1 ====================
- public PrivilegedExecutor(Executor executor, AccessControlContext acc) {
+ public PrivilegedExecutor(Executor executor, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- private RequestHook(AccessControlContext acc, PlatformEventType eventType, Runnable hook) {
+ private RequestHook(@SuppressWarnings("removal") AccessControlContext acc, PlatformEventType eventType, Runnable hook) {
================= 1 ====================
- try (BufferedReader bufferedReader =
+ try (@SuppressWarnings("removal") BufferedReader bufferedReader =
================= 1 ====================
- private static void privateCheckProxyPackageAccess(SecurityManager s, Class clazz) {
+ private static void privateCheckProxyPackageAccess(@SuppressWarnings("removal") SecurityManager s, Class clazz) {


**That's all**.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From erikj at openjdk.java.net  Mon May 17 22:30:56 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 17 May 2021 22:30:56 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: 

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang  wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

Makefile change looks ok.

-------------

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4073

From kizune at openjdk.java.net  Tue May 18 00:29:21 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 18 May 2021 00:29:21 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v9]
In-Reply-To: 
References: 
Message-ID: 

> Fix updated after first round of review.

Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:

  Fixed documentation based on CSR review feedback

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2875/files
  - new: https://git.openjdk.java.net/jdk/pull/2875/files/911bc70b..59224696

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2875&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2875&range=07-08

  Stats: 14 lines in 1 file changed: 7 ins; 6 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2875.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2875/head:pull/2875

PR: https://git.openjdk.java.net/jdk/pull/2875

From dholmes at openjdk.java.net  Tue May 18 05:01:46 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 18 May 2021 05:01:46 GMT
Subject:  RFR: 8267184: JEP 411: Add
 -Djava.security.manager=allow to tests calling System.setSecurityManager
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: 

On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang  wrote:

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas. Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

Changes to hotspot-* and serviceability look good.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4071

From alanb at openjdk.java.net  Tue May 18 05:51:41 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 18 May 2021 05:51:41 GMT
Subject:  RFR: 8267184: JEP 411: Add
 -Djava.security.manager=allow to tests calling System.setSecurityManager
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: 

On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang  wrote:

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas. Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

Marked as reviewed by alanb (Reviewer).

The changes look okay but a bit inconsistent on where -Djava...=allow is inserted for tests that already set other system properties or other parameters. Not a correctness issue, just looks odd in several places, e.g.

test/jdk/java/lang/System/LoggerFinder/BaseLoggerFinderTest/BaseLoggerFinderTest.java - the tests sets the system properties after -Xbootclasspath/a: but the change means it sets properties before and after.

test/jdk/java/lang/Class/getResource/ResourcesTest.java - you've added it in the middle of the module and class path parameters.

For uses using ProcessTools then it seems to be very random.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4071

From alanb at openjdk.java.net  Tue May 18 06:33:40 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 18 May 2021 06:33:40 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: 

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang  wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

src/java.base/share/classes/java/lang/SecurityManager.java line 315:

> 313:  *
> 314:  * @since   1.0
> 315:  * @deprecated The Security Manager is deprecated and subject to removal in a

Javadoc will prefix, in bold, "Deprecated, for removal: This API element is subject to removal in a future version". I'm just wondering if the sentence will be repeated here, can you check?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From aivanov at openjdk.java.net  Tue May 18 10:42:44 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 18 May 2021 10:42:44 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v9]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 18 May 2021 00:29:21 GMT, Alexander Zuev  wrote:

>> Fix updated after first round of review.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed documentation based on CSR review feedback

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From dfuchs at openjdk.java.net  Tue May 18 11:33:44 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 18 May 2021 11:33:44 GMT
Subject:  RFR: 8267184: JEP 411: Add
 -Djava.security.manager=allow to tests calling System.setSecurityManager
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: 

On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang  wrote:

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas. Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

I looked at serviceability, net, and corelibs. The changes look good to me - though I have one question about the NotificationEmissionTest. I believe that regardless of whether the new property is needed, test case 1 should be run in /othervm too.

test/jdk/javax/management/remote/mandatory/notif/NotificationEmissionTest.java line 34:

> 32:  * @run clean NotificationEmissionTest
> 33:  * @run build NotificationEmissionTest
> 34:  * @run main NotificationEmissionTest 1

This test case (NotificationEmissionTest 1) calls `System.setProperty("java.security.policy", policyFile);` - even though it doesn't call System.setSecurityManager(); Should the @run command line for test case 1 be modified as well?

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4071

From mullan at openjdk.java.net  Tue May 18 12:44:48 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 18 May 2021 12:44:48 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
Message-ID: 

On Tue, 18 May 2021 06:31:06 GMT, Alan Bateman  wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>
> src/java.base/share/classes/java/lang/SecurityManager.java line 315:
> 
>> 313:  *
>> 314:  * @since   1.0
>> 315:  * @deprecated The Security Manager is deprecated and subject to removal in a
> 
> Javadoc will prefix, in bold, "Deprecated, for removal: This API element is subject to removal in a future version". I'm just wondering if the sentence will be repeated here, can you check?

It includes both:
![Screen Shot 2021-05-18 at 8 41 11 AM](https://user-images.githubusercontent.com/35072269/118652730-dfb35400-b7b4-11eb-83ee-92be9136fea2.jpg)

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Tue May 18 14:01:41 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 18 May 2021 14:01:41 GMT
Subject:  RFR: 8267184: JEP 411: Add
 -Djava.security.manager=allow to tests calling System.setSecurityManager
In-Reply-To: 
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
 
Message-ID: 

On Tue, 18 May 2021 11:12:00 GMT, Daniel Fuchs  wrote:

>> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
>> 
>> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, i18n, rmi, javadoc, swing, 2d, security, hotspot-runtime, nio, xml, beans, ~~core-libs~~, ~~net~~, compiler, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
>> 
>> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
>> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
>> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
>> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
>> 
>> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
>> 
>> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
>> 
>> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
>> 
>> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
>> 
>> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
>> 
>> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
>> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>>  ```
>> 
>> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.
>
> test/jdk/javax/management/remote/mandatory/notif/NotificationEmissionTest.java line 34:
> 
>> 32:  * @run clean NotificationEmissionTest
>> 33:  * @run build NotificationEmissionTest
>> 34:  * @run main NotificationEmissionTest 1
> 
> This test case (NotificationEmissionTest 1) calls `System.setProperty("java.security.policy", policyFile);` - even though it doesn't call System.setSecurityManager(); Should the @run command line for test case 1 be modified as well?

Or maybe the policy setting line should only be called when a security manager is set? IIRC jtreg is able to restore system properties even in agentvm mode. So maybe this really doesn't matter. We just want to modify as little as possible in this PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4071

From weijun at openjdk.java.net  Tue May 18 14:07:38 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 18 May 2021 14:07:38 GMT
Subject:  RFR: 8267184: JEP 411: Add
 -Djava.security.manager=allow to tests calling System.setSecurityManager
In-Reply-To: 
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
 
Message-ID: 

On Tue, 18 May 2021 05:48:56 GMT, Alan Bateman  wrote:

> The changes look okay but a bit inconsistent on where -Djava...=allow is inserted for tests that already set other system properties or other parameters. Not a correctness issue, just looks odd in several places, e.g.
> 
> test/jdk/java/lang/System/LoggerFinder/BaseLoggerFinderTest/BaseLoggerFinderTest.java - the tests sets the system properties after -Xbootclasspath/a: but the change means it sets properties before and after.
> 
> test/jdk/java/lang/Class/getResource/ResourcesTest.java - you've added it in the middle of the module and class path parameters.
> 
> For uses using ProcessTools then it seems to be very random.

I've updated the 3 cases you mentioned and will go through more. Yes it looks good to group system property settings together. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4071

From alanb at openjdk.java.net  Tue May 18 15:22:42 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 18 May 2021 15:22:42 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
Message-ID: 

On Tue, 18 May 2021 12:42:08 GMT, Sean Mullan  wrote:

>> src/java.base/share/classes/java/lang/SecurityManager.java line 315:
>> 
>>> 313:  *
>>> 314:  * @since   1.0
>>> 315:  * @deprecated The Security Manager is deprecated and subject to removal in a
>> 
>> Javadoc will prefix, in bold, "Deprecated, for removal: This API element is subject to removal in a future version". I'm just wondering if the sentence will be repeated here, can you check?
>
> It includes both:
> ![Screen Shot 2021-05-18 at 8 41 11 AM](https://user-images.githubusercontent.com/35072269/118652730-dfb35400-b7b4-11eb-83ee-92be9136fea2.jpg)

Thanks for checking, I assumed that was the case so wondering if it should be dropped from the deprecation text to avoid the repeated sentence.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From mullan at openjdk.java.net  Tue May 18 15:49:38 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 18 May 2021 15:49:38 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
Message-ID: <0_9OMaDXfGSSqm5VdlusV4KRWnHxD2KFD5ifyV1hVFI=.1ba2b000-954e-4b23-a869-7d3aa1a909d6@github.com>

On Tue, 18 May 2021 15:19:21 GMT, Alan Bateman  wrote:

>> It includes both:
>> ![Screen Shot 2021-05-18 at 8 41 11 AM](https://user-images.githubusercontent.com/35072269/118652730-dfb35400-b7b4-11eb-83ee-92be9136fea2.jpg)
>
> Thanks for checking, I assumed that was the case so wondering if it should be dropped from the deprecation text to avoid the repeated sentence.

My feeling is that it is better to be more specific than the generic removal text as this is the most significant class that is being deprecated for removal. Also, this says "the Security Manager" (note the space between) which really encompasses more than the `java.lang.SecurityManager` API and which is explained more completely in the JEP.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From darcy at openjdk.java.net  Tue May 18 16:29:47 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 18 May 2021 16:29:47 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: 

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang  wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From chegar at openjdk.java.net  Tue May 18 16:38:42 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 18 May 2021 16:38:42 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: 

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang  wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

The changes in the net area look fine.

-------------

Marked as reviewed by chegar (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4073

From naoto at openjdk.java.net  Tue May 18 16:45:40 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 18 May 2021 16:45:40 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: 

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang  wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

Reviewed i18n/java.time/charset. They all look good.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4073

From joehw at openjdk.java.net  Tue May 18 17:30:39 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 18 May 2021 17:30:39 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: 

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang  wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

java.xml changes look good. Thanks.

-------------

Marked as reviewed by joehw (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4073

From alanb at openjdk.java.net  Tue May 18 17:39:40 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 18 May 2021 17:39:40 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: 

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang  wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

Marked as reviewed by alanb (Reviewer).

src/java.base/share/classes/java/security/AccessController.java line 877:

> 875:     @CallerSensitive
> 876:     public static  T doPrivileged(PrivilegedExceptionAction action,
> 877:                                      @SuppressWarnings("removal") AccessControlContext context, Permission... perms)

you might find it easier if you put the Permissions parameter on a new line. There are several places in AccessController where the same thing happens.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From mchung at openjdk.java.net  Tue May 18 17:43:39 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 18 May 2021 17:43:39 GMT
Subject:  RFR: 8267184: JEP 411: Add
 -Djava.security.manager=allow to tests calling System.setSecurityManager
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: 

On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang  wrote:

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, i18n, rmi, javadoc, swing, 2d, security, hotspot-runtime, nio, xml, beans, ~~core-libs~~, ~~net~~, compiler, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

I reviewed non-client areas.  Looks okay.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4071

From mchung at openjdk.java.net  Tue May 18 17:53:51 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 18 May 2021 17:53:51 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: 

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang  wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

Marked as reviewed by mchung (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Tue May 18 18:42:26 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 18 May 2021 18:42:26 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
Message-ID: 

On Tue, 18 May 2021 17:36:55 GMT, Alan Bateman  wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>
> src/java.base/share/classes/java/security/AccessController.java line 877:
> 
>> 875:     @CallerSensitive
>> 876:     public static  T doPrivileged(PrivilegedExceptionAction action,
>> 877:                                      @SuppressWarnings("removal") AccessControlContext context, Permission... perms)
> 
> you might find it easier if you put the Permissions parameter on a new line. There are several places in AccessController where the same thing happens.

My rule is that a new line is added if there's only whitespaces before the insert position and the previous line does not end with a comma. In this case, unless I move `Permission... perms` onto a new line that an annotation on a new line looks like covering both `context` and `perms`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Tue May 18 21:13:40 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 18 May 2021 21:13:40 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
Message-ID: 

On Tue, 18 May 2021 18:38:52 GMT, Weijun Wang  wrote:

>> src/java.base/share/classes/java/security/AccessController.java line 877:
>> 
>>> 875:     @CallerSensitive
>>> 876:     public static  T doPrivileged(PrivilegedExceptionAction action,
>>> 877:                                      @SuppressWarnings("removal") AccessControlContext context, Permission... perms)
>> 
>> you might find it easier if you put the Permissions parameter on a new line. There are several places in AccessController where the same thing happens.
>
> I'll try to update my auto-annotating program.

Turns out this only happens in this class:

$ rg '^\s*@SuppressWarnings("removal").*?,.'
src/java.base/share/classes/java/security/AccessController.java:449:        @SuppressWarnings("removal") AccessControlContext context, Permission... perms) {
src/java.base/share/classes/java/security/AccessController.java:514:        @SuppressWarnings("removal") AccessControlContext context, Permission... perms) {
src/java.base/share/classes/java/security/AccessController.java:877:                                     @SuppressWarnings("removal") AccessControlContext context, Permission... perms)

I'll fix them manually.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Tue May 18 21:21:45 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 18 May 2021 21:21:45 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v2]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: 

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  feedback from Sean, Phil and Alan

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4073/files
  - new: https://git.openjdk.java.net/jdk/pull/4073/files/eb6c566f..bb73093a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=00-01

  Stats: 9 lines in 3 files changed: 4 ins; 1 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Tue May 18 21:44:43 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 18 May 2021 21:44:43 GMT
Subject:  RFR: 8267184: JEP 411: Add
 -Djava.security.manager=allow to tests calling System.setSecurityManager
 [v2]
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: 

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  adjust order of VM options

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4071/files
  - new: https://git.openjdk.java.net/jdk/pull/4071/files/900c28c0..bfa955ad

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=00-01

  Stats: 59 lines in 18 files changed: 8 ins; 6 del; 45 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4071.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4071/head:pull/4071

PR: https://git.openjdk.java.net/jdk/pull/4071

From weijun at openjdk.java.net  Wed May 19 13:47:54 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 13:47:54 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v2]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
Message-ID: <8mVaKSBeyfyVBHsp67PuOC1G7--flmHQzygrQTyrgGE=.ed4f6dd9-e0af-4058-97f5-cf5ab3651aa4@github.com>

On Tue, 18 May 2021 21:21:45 GMT, Weijun Wang  wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback from Sean, Phil and Alan

A new commit fixing `awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java` test in tier4. The test compares stderr output with a known value but we have a new warning written to stderr now. It's now using stdout instead. @prrace, Please confirm this is acceptable. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Wed May 19 13:47:53 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 13:47:53 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v3]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: 

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
> 
> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4073/files
  - new: https://git.openjdk.java.net/jdk/pull/4073/files/bb73093a..c4221b5f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

PR: https://git.openjdk.java.net/jdk/pull/4073

From prr at openjdk.java.net  Wed May 19 18:16:57 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 May 2021 18:16:57 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
Message-ID: 

On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang  wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

test/jdk/java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java line 59:

> 57:                 ProcessCommunicator
> 58:                         .executeChildProcess(Consumer.class, new String[0]);
> 59:         if (!"Hello".equals(processResults.getStdOut())) {

Who or what prompted this change ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From prr at openjdk.java.net  Wed May 19 18:19:49 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 May 2021 18:19:49 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
Message-ID: 

On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang  wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

This change is so large that github won't even display the list of files so I can't jump to where I want to go !
And when I try to scroll I get just a blank page.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From prr at openjdk.java.net  Wed May 19 18:29:41 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 May 2021 18:29:41 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
Message-ID: 

On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang  wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

src/java.desktop/share/classes/java/awt/Component.java line 217:

> 215:  * @author      Sami Shaio
> 216:  */
> 217: @SuppressWarnings("removal")

Why is this placed on the *entire class* ??
This class is 10535 lines long and mentions AccessControl something like 8 places it uses AccessController or AcessControlContext.

src/java.desktop/share/classes/java/awt/Container.java line 97:

> 95:  * @since     1.0
> 96:  */
> 97: @SuppressWarnings("removal")

Same issue as with Component. a > 5,000 line file that uses AccessController in just 4 places.

Where else are you adding this to entire classes instead of the specific site ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Wed May 19 18:41:44 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 18:41:44 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
Message-ID: 

On Wed, 19 May 2021 18:26:25 GMT, Phil Race  wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
>
> src/java.desktop/share/classes/java/awt/Component.java line 217:
> 
>> 215:  * @author      Sami Shaio
>> 216:  */
>> 217: @SuppressWarnings("removal")
> 
> Why is this placed on the *entire class* ??
> This class is 10535 lines long and mentions AccessControl something like 8 places it uses AccessController or AcessControlContext.

This happens when a deprecated method is called inside a static block. The annotation can only be added to a declaration and here it must be the whole class. The call in this file is

        s = java.security.AccessController.doPrivileged(
                                                        new GetPropertyAction("awt.image.redrawrate"));

> src/java.desktop/share/classes/java/awt/Container.java line 97:
> 
>> 95:  * @since     1.0
>> 96:  */
>> 97: @SuppressWarnings("removal")
> 
> Same issue as with Component. a > 5,000 line file that uses AccessController in just 4 places.
> 
> Where else are you adding this to entire classes instead of the specific site ?

Similar as the one above, it's because of

    static {
        // Don't lazy-read because every app uses invalidate()
        isJavaAwtSmartInvalidate = AccessController.doPrivileged(
                new GetBooleanAction("java.awt.smartInvalidate"));
    }

> test/jdk/java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java line 59:
> 
>> 57:                 ProcessCommunicator
>> 58:                         .executeChildProcess(Consumer.class, new String[0]);
>> 59:         if (!"Hello".equals(processResults.getStdOut())) {
> 
> Who or what prompted this change ?

The child process is started with `-Djava.security.manager=allow` (after the other PR) and a warning will be printed to stderr. Therefore I move the message to stdout.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Wed May 19 18:46:46 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 18:46:46 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
Message-ID: 

On Wed, 19 May 2021 18:39:10 GMT, Weijun Wang  wrote:

>> src/java.desktop/share/classes/java/awt/Container.java line 97:
>> 
>>> 95:  * @since     1.0
>>> 96:  */
>>> 97: @SuppressWarnings("removal")
>> 
>> Same issue as with Component. a > 5,000 line file that uses AccessController in just 4 places.
>> 
>> Where else are you adding this to entire classes instead of the specific site ?
>
> Similar as the one above, it's because of
> 
>     static {
>         // Don't lazy-read because every app uses invalidate()
>         isJavaAwtSmartInvalidate = AccessController.doPrivileged(
>                 new GetBooleanAction("java.awt.smartInvalidate"));
>     }

We are thinking of more tweaks after this overall change to make the annotation more precise. For example, in this case we can assign the `doPrivileged` result to a local variable right at its declaration, and then assign it to `isJavaAwtSmartInvalidate`. Some people might think this is ugly. Such manual code changes need to done little by little to ease code reviewing.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Wed May 19 18:51:43 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 18:51:43 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
 
Message-ID: 

On Wed, 19 May 2021 18:44:06 GMT, Weijun Wang  wrote:

>> Similar as the one above, it's because of
>> 
>>     static {
>>         // Don't lazy-read because every app uses invalidate()
>>         isJavaAwtSmartInvalidate = AccessController.doPrivileged(
>>                 new GetBooleanAction("java.awt.smartInvalidate"));
>>     }
>
> We are thinking of more tweaks after this overall change to make the annotation more precise. For example, in this case we can assign the `doPrivileged` result to a local variable right at its declaration, and then assign it to `isJavaAwtSmartInvalidate`. Some people might think this is ugly. Such manual code changes need to done little by little to ease code reviewing.

I know it's not easy to read the commit and that's why I make the 3rd commit totally automatic. Hopefully you have more confidence on the program than my hand. All annotations are added to the nearest declarations.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From prr at openjdk.java.net  Wed May 19 19:34:48 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 May 2021 19:34:48 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
Message-ID: <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>

On Wed, 19 May 2021 18:38:39 GMT, Weijun Wang  wrote:

>> src/java.desktop/share/classes/java/awt/Component.java line 217:
>> 
>>> 215:  * @author      Sami Shaio
>>> 216:  */
>>> 217: @SuppressWarnings("removal")
>> 
>> Why is this placed on the *entire class* ??
>> This class is 10535 lines long and mentions AccessControl something like 8 places it uses AccessController or AcessControlContext.
>
> This happens when a deprecated method is called inside a static block. The annotation can only be added to a declaration and here it must be the whole class. The call in this file is
> 
>         s = java.security.AccessController.doPrivileged(
>                                                         new GetPropertyAction("awt.image.redrawrate"));

That's a sad limitation of the annotation stuff then, but I don't think that it is insurmountable.
You can define a static private method to contain this and call it from the static initializer block.
Much better than applying the annotation to an entire class.

--- a/src/java.desktop/share/classes/java/awt/Component.java
+++ b/src/java.desktop/share/classes/java/awt/Component.java
@@ -618,6 +618,17 @@ public abstract class Component implements ImageObserver, MenuContainer,
      */
     static boolean isInc;
     static int incRate;
+
+    private static void initIncRate() {
+        String s = java.security.AccessController.doPrivileged(
+                                 new GetPropertyAction("awt.image.incrementaldraw"));
+        isInc = (s == null || s.equals("true"));
+
+        s = java.security.AccessController.doPrivileged(
+                          new GetPropertyAction("awt.image.redrawrate"));
+        incRate = (s != null) ? Integer.parseInt(s) : 100;
+    }
+
     static {
         /* ensure that the necessary native libraries are loaded */
         Toolkit.loadLibraries();
@@ -625,14 +636,7 @@ public abstract class Component implements ImageObserver, MenuContainer,
         if (!GraphicsEnvironment.isHeadless()) {
             initIDs();
         }
-
-        String s = java.security.AccessController.doPrivileged(
-                                                               new GetPropertyAction("awt.image.incrementaldraw"));
-        isInc = (s == null || s.equals("true"));
-
-        s = java.security.AccessController.doPrivileged(
-                                                        new GetPropertyAction("awt.image.redrawrate"));
-        incRate = (s != null) ? Integer.parseInt(s) : 100;
+        initIncRate();
     }

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From mullan at openjdk.java.net  Wed May 19 20:33:43 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Wed, 19 May 2021 20:33:43 GMT
Subject:  RFR: 8267184: JEP 411: Add
 -Djava.security.manager=allow to tests calling System.setSecurityManager
 [v2]
In-Reply-To: 
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
 
Message-ID: 

On Tue, 18 May 2021 21:44:43 GMT, Weijun Wang  wrote:

>> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
>> 
>> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
>> 
>> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
>> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
>> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
>> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
>> 
>> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
>> 
>> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
>> 
>> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
>> 
>> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
>> 
>> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
>> 
>> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
>> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>>  ```
>> 
>> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust order of VM options

The changes to the security tests look good.

-------------

Marked as reviewed by mullan (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4071

From weijun at openjdk.java.net  Wed May 19 21:56:30 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 21:56:30 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v3]
In-Reply-To: <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
Message-ID: 

On Wed, 19 May 2021 19:31:24 GMT, Phil Race  wrote:

>> This happens when a deprecated method is called inside a static block. The annotation can only be added to a declaration and here it must be the whole class. The call in this file is
>> 
>>         s = java.security.AccessController.doPrivileged(
>>                                                         new GetPropertyAction("awt.image.redrawrate"));
>
> That's a sad limitation of the annotation stuff then, but I don't think that it is insurmountable.
> You can define a static private method to contain this and call it from the static initializer block.
> Much better than applying the annotation to an entire class.
> 
> --- a/src/java.desktop/share/classes/java/awt/Component.java
> +++ b/src/java.desktop/share/classes/java/awt/Component.java
> @@ -618,6 +618,17 @@ public abstract class Component implements ImageObserver, MenuContainer,
>       */
>      static boolean isInc;
>      static int incRate;
> +
> +    private static void initIncRate() {
> +        String s = java.security.AccessController.doPrivileged(
> +                                 new GetPropertyAction("awt.image.incrementaldraw"));
> +        isInc = (s == null || s.equals("true"));
> +
> +        s = java.security.AccessController.doPrivileged(
> +                          new GetPropertyAction("awt.image.redrawrate"));
> +        incRate = (s != null) ? Integer.parseInt(s) : 100;
> +    }
> +
>      static {
>          /* ensure that the necessary native libraries are loaded */
>          Toolkit.loadLibraries();
> @@ -625,14 +636,7 @@ public abstract class Component implements ImageObserver, MenuContainer,
>          if (!GraphicsEnvironment.isHeadless()) {
>              initIDs();
>          }
> -
> -        String s = java.security.AccessController.doPrivileged(
> -                                                               new GetPropertyAction("awt.image.incrementaldraw"));
> -        isInc = (s == null || s.equals("true"));
> -
> -        s = java.security.AccessController.doPrivileged(
> -                                                        new GetPropertyAction("awt.image.redrawrate"));
> -        incRate = (s != null) ? Integer.parseInt(s) : 100;
> +        initIncRate();
>      }

Correct, there are ways to modify the code to make it more annotation-friendly. We thought about whether it's good to do it before adding the annotations or after it. Our decision now is to do it after because it will be more easy to see why it's necessary and we can take time to do them little by little. A new enhancement at https://bugs.openjdk.java.net/browse/JDK-8267432 is filed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From prr at openjdk.java.net  Wed May 19 22:07:36 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 May 2021 22:07:36 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 
Message-ID: 

On Wed, 19 May 2021 21:53:35 GMT, Weijun Wang  wrote:

>> That's a sad limitation of the annotation stuff then, but I don't think that it is insurmountable.
>> You can define a static private method to contain this and call it from the static initializer block.
>> Much better than applying the annotation to an entire class.
>> 
>> --- a/src/java.desktop/share/classes/java/awt/Component.java
>> +++ b/src/java.desktop/share/classes/java/awt/Component.java
>> @@ -618,6 +618,17 @@ public abstract class Component implements ImageObserver, MenuContainer,
>>       */
>>      static boolean isInc;
>>      static int incRate;
>> +
>> +    private static void initIncRate() {
>> +        String s = java.security.AccessController.doPrivileged(
>> +                                 new GetPropertyAction("awt.image.incrementaldraw"));
>> +        isInc = (s == null || s.equals("true"));
>> +
>> +        s = java.security.AccessController.doPrivileged(
>> +                          new GetPropertyAction("awt.image.redrawrate"));
>> +        incRate = (s != null) ? Integer.parseInt(s) : 100;
>> +    }
>> +
>>      static {
>>          /* ensure that the necessary native libraries are loaded */
>>          Toolkit.loadLibraries();
>> @@ -625,14 +636,7 @@ public abstract class Component implements ImageObserver, MenuContainer,
>>          if (!GraphicsEnvironment.isHeadless()) {
>>              initIDs();
>>          }
>> -
>> -        String s = java.security.AccessController.doPrivileged(
>> -                                                               new GetPropertyAction("awt.image.incrementaldraw"));
>> -        isInc = (s == null || s.equals("true"));
>> -
>> -        s = java.security.AccessController.doPrivileged(
>> -                                                        new GetPropertyAction("awt.image.redrawrate"));
>> -        incRate = (s != null) ? Integer.parseInt(s) : 100;
>> +        initIncRate();
>>      }
>
> Correct, there are ways to modify the code to make it more annotation-friendly. We thought about whether it's good to do it before adding the annotations or after it. Our decision now is to do it after because it will be more easy to see why it's necessary and we can take time to do them little by little. A new enhancement at https://bugs.openjdk.java.net/browse/JDK-8267432 is filed.

I don't think it is a separate P4 enhancement (?) that someone will (maybe) do next release.
I think it should all be taken care of as part of this proposed change.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Wed May 19 22:17:34 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 22:17:34 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 
 
Message-ID: <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>

On Wed, 19 May 2021 22:04:57 GMT, Phil Race  wrote:

>> Correct, there are ways to modify the code to make it more annotation-friendly. We thought about whether it's good to do it before adding the annotations or after it. Our decision now is to do it after because it will be more easy to see why it's necessary and we can take time to do them little by little. A new enhancement at https://bugs.openjdk.java.net/browse/JDK-8267432 is filed.
>
> I don't think it is a separate P4 enhancement (?) that someone will (maybe) do next release.
> I think it should all be taken care of as part of this proposed change.

I just made it P3 (P4 was the default value), and I will target it to 17 once JEP 411 is targeted 17. But I think it's probably not a good idea to include it inside *this* PR. There are some middle ground where it's debatable if a change is worth doing (Ex: which is uglier between an a-liitle-faraway-annotation and a temporary variable?) so it's not obvious what the scope of the refactoring can be. Thus it will be divided into smaller sub-tasks. It's not totally impossible that part of the work will be delayed to next release.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From prr at openjdk.java.net  Wed May 19 23:53:35 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 May 2021 23:53:35 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v3]
In-Reply-To: <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 
 
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
Message-ID: 

On Wed, 19 May 2021 22:14:20 GMT, Weijun Wang  wrote:

>> I don't think it is a separate P4 enhancement (?) that someone will (maybe) do next release.
>> I think it should all be taken care of as part of this proposed change.
>
> I just made it P3 (P4 was the default value), and I will target it to 17 once JEP 411 is targeted 17. But I think it's probably not a good idea to include it inside *this* PR. There are some middle ground where it's debatable if a change is worth doing (Ex: which is uglier between an a-liitle-faraway-annotation and a temporary variable?) so it's not obvious what the scope of the refactoring can be. Thus it will be divided into smaller sub-tasks. It's not totally impossible that part of the work will be delayed to next release.

Well .. as an enhancement (P3 or otherwise) I can see it being dropped and definitely if it misses the fork,
and I don't get why you can't do it here. And if it isn't done the JEP isn't really ready.
I already pasted the patch for Component.java and it took about 60 seconds to do that.
Then yes, you would have to deal with the fact that now you need to reapply your automated tool to the file but this is just work you'd have to have done anyway if it was already refactored.

I only *noticed* Component and Container. And stopped there to raise the question. How many more cases are there ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Thu May 20 02:09:42 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 20 May 2021 02:09:42 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 
 
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 
Message-ID: 

On Wed, 19 May 2021 23:50:04 GMT, Phil Race  wrote:

>> I just made it P3 (P4 was the default value), and I will target it to 17 once JEP 411 is targeted 17. But I think it's probably not a good idea to include it inside *this* PR. There are some middle ground where it's debatable if a change is worth doing (Ex: which is uglier between an a-liitle-faraway-annotation and a temporary variable?) so it's not obvious what the scope of the refactoring can be. Thus it will be divided into smaller sub-tasks. It's not totally impossible that part of the work will be delayed to next release.
>
> Well .. as an enhancement (P3 or otherwise) I can see it being dropped and definitely if it misses the fork,
> and I don't get why you can't do it here. And if it isn't done the JEP isn't really ready.
> I already pasted the patch for Component.java and it took about 60 seconds to do that.
> Then yes, you would have to deal with the fact that now you need to reapply your automated tool to the file but this is just work you'd have to have done anyway if it was already refactored.
> 
> I only *noticed* Component and Container. And stopped there to raise the question. How many more cases are there ?

I can make it a bug.

I don't want to do it here is because it involves indefinite amount of manual work and we will see everyone having their preferences. The more time we spend on this PR the more likely there will be merge conflict. There are just too many files here.

And no matter if we include that change in this PR or after it, it will be after the automatic conversion. In fact, the data about which cases are more worth fixing come from the automatic conversion itself. Also, as the manual work will be done part by part, if the automatic conversion is after it, there will be rounds and rounds of history rewriting and force push. This is quite unfriendly to the reviewers.

Altogether, there are 117 class-level annotations. Unfortunately, `java.awt.Component` is the one with the biggest class -- estimated number of bytes that the annotation covers is over 380K. In the client area, the 2nd place is `java.awt.Container`, and then we have `sun.font.SunFontManager`, `java.awt.Window`, and `java.awt.Toolkit` which are over 100KB, and other 25 classes over 10KB, and other 11 classes smaller than 10KB.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Thu May 20 02:12:33 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 20 May 2021 02:12:33 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 
 
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 
 
Message-ID: 

On Thu, 20 May 2021 02:06:46 GMT, Weijun Wang  wrote:

>> Well .. as an enhancement (P3 or otherwise) I can see it being dropped and definitely if it misses the fork,
>> and I don't get why you can't do it here. And if it isn't done the JEP isn't really ready.
>> I already pasted the patch for Component.java and it took about 60 seconds to do that.
>> Then yes, you would have to deal with the fact that now you need to reapply your automated tool to the file but this is just work you'd have to have done anyway if it was already refactored.
>> 
>> I only *noticed* Component and Container. And stopped there to raise the question. How many more cases are there ?
>
> I can make it a bug.
> 
> I don't want to do it here is because it involves indefinite amount of manual work and we will see everyone having their preferences. The more time we spend on this PR the more likely there will be merge conflict. There are just too many files here.
> 
> And no matter if we include that change in this PR or after it, it will be after the automatic conversion. In fact, the data about which cases are more worth fixing come from the automatic conversion itself. Also, as the manual work will be done part by part, if the automatic conversion is after it, there will be rounds and rounds of history rewriting and force push. This is quite unfriendly to the reviewers.
> 
> Altogether, there are 117 class-level annotations. Unfortunately, `java.awt.Component` is the one with the biggest class -- estimated number of bytes that the annotation covers is over 380K. In the client area, the 2nd place is `java.awt.Container`, and then we have `sun.font.SunFontManager`, `java.awt.Window`, and `java.awt.Toolkit` which are over 100KB, and other 25 classes over 10KB, and other 11 classes smaller than 10KB.

By converting JDK-8267432 to a bug, there is an extra benefit that we can fix it after RDP. So I'll convert it now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From prr at openjdk.java.net  Thu May 20 04:08:38 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 20 May 2021 04:08:38 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 
 
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 
 
 
Message-ID: <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com>

On Thu, 20 May 2021 02:09:57 GMT, Weijun Wang  wrote:

>> I can make it a bug.
>> 
>> I don't want to do it here is because it involves indefinite amount of manual work and we will see everyone having their preferences. The more time we spend on this PR the more likely there will be merge conflict. There are just too many files here.
>> 
>> And no matter if we include that change in this PR or after it, it will be after the automatic conversion. In fact, the data about which cases are more worth fixing come from the automatic conversion itself. Also, as the manual work will be done part by part, if the automatic conversion is after it, there will be rounds and rounds of history rewriting and force push. This is quite unfriendly to the reviewers.
>> 
>> Altogether, there are 117 class-level annotations. Unfortunately, `java.awt.Component` is the one with the biggest class -- estimated number of bytes that the annotation covers is over 380K. In the client area, the 2nd place is `java.awt.Container`, and then we have `sun.font.SunFontManager`, `java.awt.Window`, and `java.awt.Toolkit` which are over 100KB, and other 25 classes over 10KB, and other 11 classes smaller than 10KB.
>
> By converting JDK-8267432 to a bug, there is an extra benefit that we can fix it after RDP. So I'll convert it now.

That is unfortunate, but nonetheless I think required to be done.
We have acknowledeged this can't reasonably be called an RFE, so the JEP is introducing bugs/technical debt/call it what you will. This should generally be part of a sandbox for the JEP and fixed before integration of the JEP.
>From my point of view it is a blocker.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From prr at openjdk.java.net  Thu May 20 04:25:29 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 20 May 2021 04:25:29 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v3]
In-Reply-To: <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 
 
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 
 
 
 <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com>
Message-ID: 

On Thu, 20 May 2021 04:05:23 GMT, Phil Race  wrote:

>> By converting JDK-8267432 to a bug, there is an extra benefit that we can fix it after RDP. So I'll convert it now.
>
> That is unfortunate, but nonetheless I think required to be done.
> We have acknowledeged this can't reasonably be called an RFE, so the JEP is introducing bugs/technical debt/call it what you will. This should generally be part of a sandbox for the JEP and fixed before integration of the JEP.
> From my point of view it is a blocker.

The JEP isn't PTT for 17 so there's plenty of time isn't there ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From alanb at openjdk.java.net  Thu May 20 07:08:35 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 20 May 2021 07:08:35 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 
 
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 
 
 
 <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com>
 
Message-ID: 

On Thu, 20 May 2021 04:22:32 GMT, Phil Race  wrote:

>> That is unfortunate, but nonetheless I think required to be done.
>> We have acknowledeged this can't reasonably be called an RFE, so the JEP is introducing bugs/technical debt/call it what you will. This should generally be part of a sandbox for the JEP and fixed before integration of the JEP.
>> From my point of view it is a blocker.
>
> The JEP isn't PTT for 17 so there's plenty of time isn't there ?

There are 827 files in this patch. Phil is right that adding SW at the class level is introducing technical debt but if addressing that requires refactoring and re-testing of AWT or font code then it would be better to have someone from that area working on. Is there any reason why this can't be going on now on awt-dev/2d-dev and integrated immediately after JEP 411? I don't think we should put Max through the wringer here as there are too many areas to cover.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From kizune at openjdk.java.net  Thu May 20 07:30:00 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 20 May 2021 07:30:00 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v10]
In-Reply-To: 
References: 
Message-ID: 

> Fix updated after first round of review.

Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:

  Empty 
 tag before @implSpec causes warning during javadoc generation

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2875/files
  - new: https://git.openjdk.java.net/jdk/pull/2875/files/59224696..09c7f8d7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2875&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2875&range=08-09

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2875.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2875/head:pull/2875

PR: https://git.openjdk.java.net/jdk/pull/2875

From serb at openjdk.java.net  Thu May 20 07:43:40 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 20 May 2021 07:43:40 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v7]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Mon, 17 May 2021 05:08:13 GMT, Alexander Zuev  wrote:

>> src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 271:
>> 
>>> 269:     * Example: 
>>> 270:     * FileSystemView fsv = FileSystemView.getFileSystemView();
>>> 271:     * Icon icon = fsv.getSystemIcon("application.exe", 64);
>> 
>> Shouldn't the first parameter be a File instance instead of String?
>> `Icon icon = fsv.getSystemIcon(new File("application.exe"), 64);`
>
> Good catch! Yes, fixed both here and in CSR.

Are we sure that all possible paths can be pointed by the file object? Especially some "Windows Libraries" which are accessed by the shell folder?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From serb at openjdk.java.net  Thu May 20 07:54:36 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 20 May 2021 07:54:36 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v10]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 20 May 2021 07:30:00 GMT, Alexander Zuev  wrote:

>> Fix updated after first round of review.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Empty 
 tag before @implSpec causes warning during javadoc generation

src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 272:

> 270:     * returned is a multi-resolution icon image,
> 271:     * which allows better support for High DPI environments
> 272:     * with different scaling factors.

Is the above text correct on all platforms? If it is not always MRI then how the user should use the icon? instanceof+cast? BTW an example does not show how to solve the bug itself, on how to access the "large icons".

Need to clarify: the implSpec is a part of the specification so can we point the non public "ShellFolder" class?

src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 275:

> 273:     *
> 274:     * @param f a {@code File} object
> 275:     * @param size width and height of the icon in virtual pixels

What are the "virtual pixels"? I remember we refer to something similar by the point in the "user space coordinate system" Or probably we use the virtual pixels somewhere?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From kizune at openjdk.java.net  Thu May 20 08:10:42 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 20 May 2021 08:10:42 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v10]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 20 May 2021 07:46:28 GMT, Sergey Bylokhov  wrote:

> What are the "virtual pixels"? I remember we refer to something similar by the point in the "user space coordinate system" Or probably we use the virtual pixels somewhere?

It is to say that the sizes are given in the same pixels as other components in the container and are subject to be rendered with different resolution based on the display scaling factor with preserving of relative sizes and proportions. The same terminology is used i.e. in SurfaceData.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From kizune at openjdk.java.net  Thu May 20 08:16:35 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 20 May 2021 08:16:35 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v10]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 20 May 2021 07:47:02 GMT, Sergey Bylokhov  wrote:

>> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Empty 
 tag before @implSpec causes warning during javadoc generation
>
> src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 272:
> 
>> 270:     * returned is a multi-resolution icon image,
>> 271:     * which allows better support for High DPI environments
>> 272:     * with different scaling factors.
> 
> Is the above text correct on all platforms? If it is not always MRI then how the user should use the icon? instanceof+cast? BTW an example does not show how to solve the bug itself, on how to access the "large icons".
> 
> Need to clarify: the implSpec is a part of the specification so can we point the non public "ShellFolder" class?

implSpec marks that the paragraph below describes the details and logic of the default implementation and not the API specification. This tag also says that it can be changed in overriding or extending methods so it is Ok to specify non-public class to help describe the implementation specifics.

As for the correctness on all platforms - that's the end goal of this new method and i believe it should be implemented this way everywhere where technically possible. But exact implementation on all platforms except Windows is outside of the scope of this exact changeset.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From serb at openjdk.java.net  Thu May 20 08:20:47 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 20 May 2021 08:20:47 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v10]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Thu, 20 May 2021 08:07:48 GMT, Alexander Zuev  wrote:

>> src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 275:
>> 
>>> 273:     *
>>> 274:     * @param f a {@code File} object
>>> 275:     * @param size width and height of the icon in virtual pixels
>> 
>> What are the "virtual pixels"? I remember we refer to something similar by the point in the "user space coordinate system" Or probably we use the virtual pixels somewhere?
>
>> What are the "virtual pixels"? I remember we refer to something similar by the point in the "user space coordinate system" Or probably we use the virtual pixels somewhere?
> 
> It is to say that the sizes are given in the same pixels as other components in the container and are subject to be rendered with different resolution based on the display scaling factor with preserving of relative sizes and proportions. The same terminology is used i.e. in SurfaceData.

SurfaceData is not a public class, do we use this term somewhere in the spec? If not then it will be better to use size/points in the user space coordinate system, it is used already in the java2d.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From serb at openjdk.java.net  Thu May 20 08:29:41 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 20 May 2021 08:29:41 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v10]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Thu, 20 May 2021 08:13:21 GMT, Alexander Zuev  wrote:

>> src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 272:
>> 
>>> 270:     * returned is a multi-resolution icon image,
>>> 271:     * which allows better support for High DPI environments
>>> 272:     * with different scaling factors.
>> 
>> Is the above text correct on all platforms? If it is not always MRI then how the user should use the icon? instanceof+cast? BTW an example does not show how to solve the bug itself, on how to access the "large icons".
>> 
>> Need to clarify: the implSpec is a part of the specification so can we point the non public "ShellFolder" class?
>
> implSpec marks that the paragraph below describes the details and logic of the default implementation and not the API specification. This tag also says that it can be changed in overriding or extending methods so it is Ok to specify non-public class to help describe the implementation specifics.
> 
> As for the correctness on all platforms - that's the end goal of this new method and i believe it should be implemented this way everywhere where technically possible. But exact implementation on all platforms except Windows is outside of the scope of this exact changeset.

The @implSpec is part of the specification, it is different from the @implNote, no?
https://bugs.openjdk.java.net/browse/JDK-8266541?focusedCommentId=14419988&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14419988

If we will specify this method in a way that will require support on all platforms we will get tck-red immediately after this push.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From kizune at openjdk.java.net  Thu May 20 08:29:44 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 20 May 2021 08:29:44 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v10]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: <7vA_X9_ewormZz-Iw8597kYrHT3MYorOUuNlGZQcRKY=.eef758f1-7d53-4085-916d-1f462d659346@github.com>

On Thu, 20 May 2021 08:18:02 GMT, Sergey Bylokhov  wrote:

>>> What are the "virtual pixels"? I remember we refer to something similar by the point in the "user space coordinate system" Or probably we use the virtual pixels somewhere?
>> 
>> It is to say that the sizes are given in the same pixels as other components in the container and are subject to be rendered with different resolution based on the display scaling factor with preserving of relative sizes and proportions. The same terminology is used i.e. in SurfaceData.
>
> SurfaceData is not a public class, do we use this term somewhere in the spec? If not then it will be better to use size/points in the user space coordinate system, it is used already in the java2d.

The CSR is already approved and changing specification at this point will require to roll it back to draft and then going trough the approval process again which in turn risks this change not to make it in the upcoming LTS release. I would prefer to integrate it and create a follow-up bug to clarify the wording where we can discuss the matter and - if it is worth it - to submit a new CSR to amend the specification.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From kizune at openjdk.java.net  Thu May 20 10:39:42 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 20 May 2021 10:39:42 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v10]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Thu, 20 May 2021 08:25:25 GMT, Sergey Bylokhov  wrote:

> The @implSpec is part of the specification, it is different from the @implNote, no?
> https://bugs.openjdk.java.net/browse/JDK-8266541?focusedCommentId=14419988&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14419988
> 
> If we will specify this method in a way that will require support on all platforms we will get tck-red immediately after this push.

Not exactly. The implNote is a note for future maintainers or people who will extend the functionality of the method. There will be no tck-red because the method is working and we did noted that we are taking into consideration the icon size and whenever technical possible we should return the multiresolution icon. So, for example, on Linux code
`        FileSystemView fsv = FileSystemView.getFileSystemView();

        Icon icon = fsv.getSystemIcon(new File("."));
        Icon icon2 = fsv.getSystemIcon(new File("."), 16);
        System.out.println("icon = " + icon);
        System.out.println("icon2 = " + icon2);
`
will get icon and icon2 as the same single-resolution icon - but that will change when underlying implementation will be fixed. Right now it is not technical possible to return multi-resolution icon - we do not do it on Linux. Implementing the underlaying code for different system, as i said, is outside of the scope of this change.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From aivanov at openjdk.java.net  Thu May 20 14:58:43 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 20 May 2021 14:58:43 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v10]
In-Reply-To: <7vA_X9_ewormZz-Iw8597kYrHT3MYorOUuNlGZQcRKY=.eef758f1-7d53-4085-916d-1f462d659346@github.com>
References: 
 
 
 
 
 <7vA_X9_ewormZz-Iw8597kYrHT3MYorOUuNlGZQcRKY=.eef758f1-7d53-4085-916d-1f462d659346@github.com>
Message-ID: <6nuXr_47TELjEEJ0ECmiuPx7P-OLUH7otsUkckJldJ8=.08a2ea69-c9e0-4d76-8410-17500e7aa727@github.com>

On Thu, 20 May 2021 08:26:07 GMT, Alexander Zuev  wrote:

>> SurfaceData is not a public class, do we use this term somewhere in the spec? If not then it will be better to use size/points in the user space coordinate system, it is used already in the java2d.
>
> The CSR is already approved and changing specification at this point will require to roll it back to draft and then going trough the approval process again which in turn risks this change not to make it in the upcoming LTS release. I would prefer to integrate it and create a follow-up bug to clarify the wording where we can discuss the matter and - if it is worth it - to submit a new CSR to amend the specification.

If *user coordinate system* is used in similar context in other methods, we should change the wording to match it. I don't mind using a new bug to clarify *virtual pixels*.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From serb at openjdk.java.net  Thu May 20 16:09:42 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 20 May 2021 16:09:42 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v10]
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: 

On Thu, 20 May 2021 10:36:39 GMT, Alexander Zuev  wrote:

>> The @implSpec is part of the specification, it is different from the @implNote, no?
>> https://bugs.openjdk.java.net/browse/JDK-8266541?focusedCommentId=14419988&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14419988
>> 
>> If we will specify this method in a way that will require support on all platforms we will get tck-red immediately after this push.
>
>> The @implSpec is part of the specification, it is different from the @implNote, no?
>> https://bugs.openjdk.java.net/browse/JDK-8266541?focusedCommentId=14419988&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14419988
>> 
>> If we will specify this method in a way that will require support on all platforms we will get tck-red immediately after this push.
> 
> Not exactly. The implNote is a note for future maintainers or people who will extend the functionality of the method. There will be no tck-red because the method is working and we did noted that we are taking into consideration the icon size and whenever technical possible we should return the multiresolution icon. So, for example, on Linux code
> `        FileSystemView fsv = FileSystemView.getFileSystemView();
> 
>         Icon icon = fsv.getSystemIcon(new File("."));
>         Icon icon2 = fsv.getSystemIcon(new File("."), 16);
>         System.out.println("icon = " + icon);
>         System.out.println("icon2 = " + icon2);
> `
> will get icon and icon2 as the same single-resolution icon - but that will change when underlying implementation will be fixed. Right now it is not technical possible to return multi-resolution icon - we do not do it on Linux. Implementing the underlaying code for different system, as i said, is outside of the scope of this change.

The implspec is a specification and we cannot refer to non-public classes in that documentation.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From serb at openjdk.java.net  Thu May 20 16:09:42 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 20 May 2021 16:09:42 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v7]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: <1WLwml_6PHy_gkPSSz18FpM8AEiFCVDGfR1S06ZxBGk=.b245e8e7-686c-4018-853b-984a35c1fecd@github.com>

On Thu, 20 May 2021 07:40:35 GMT, Sergey Bylokhov  wrote:

>> Good catch! Yes, fixed both here and in CSR.
>
> Are we sure that all possible paths can be pointed by the file object? Especially some "Windows Libraries" which are accessed by the shell folder?

Later we say that this method returns null for non-existed files. is it always correct? I am not sure that the file created for the library report true for the exists() method; DId we test this usecase?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From serb at openjdk.java.net  Thu May 20 16:09:44 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 20 May 2021 16:09:44 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v10]
In-Reply-To: 
References: 
 
Message-ID: <9F_rdHvAvvU0lzKX0edszbTNSaSdc-VpLmaaV_SdzNE=.37c9c016-22e2-497f-b711-93f9a45db7f8@github.com>

On Thu, 20 May 2021 07:30:00 GMT, Alexander Zuev  wrote:

>> Fix updated after first round of review.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Empty 
 tag before @implSpec causes warning during javadoc generation

test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java line 72:

> 70:             if (icon.getImage() instanceof MultiResolutionImage) {
> 71:                 MultiResolutionImage mri = (MultiResolutionImage) icon.getImage();
> 72:                 if (mri.getResolutionVariant(size, size) == null) {

This is to describe one of my questions above, is this instanceof+cast cannot be improved? Why we cannot always wrap the data in the MRI and if we have only one icon return the MRI with one resolution?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From serb at openjdk.java.net  Thu May 20 16:17:36 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 20 May 2021 16:17:36 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v10]
In-Reply-To: 
References: 
 
 
 
 
 
 
Message-ID: 

On Thu, 20 May 2021 16:01:32 GMT, Sergey Bylokhov  wrote:

>>> The @implSpec is part of the specification, it is different from the @implNote, no?
>>> https://bugs.openjdk.java.net/browse/JDK-8266541?focusedCommentId=14419988&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14419988
>>> 
>>> If we will specify this method in a way that will require support on all platforms we will get tck-red immediately after this push.
>> 
>> Not exactly. The implNote is a note for future maintainers or people who will extend the functionality of the method. There will be no tck-red because the method is working and we did noted that we are taking into consideration the icon size and whenever technical possible we should return the multiresolution icon. So, for example, on Linux code
>> `        FileSystemView fsv = FileSystemView.getFileSystemView();
>> 
>>         Icon icon = fsv.getSystemIcon(new File("."));
>>         Icon icon2 = fsv.getSystemIcon(new File("."), 16);
>>         System.out.println("icon = " + icon);
>>         System.out.println("icon2 = " + icon2);
>> `
>> will get icon and icon2 as the same single-resolution icon - but that will change when underlying implementation will be fixed. Right now it is not technical possible to return multi-resolution icon - we do not do it on Linux. Implementing the underlaying code for different system, as i said, is outside of the scope of this change.
>
> My point was that the implspec is a normative specification and we cannot refer to non-public classes in that documentation.

As for the example on Linux, how it will work for different sizes?
   Icon icon1 = fsv.getSystemIcon(new File("."), 16);
   Icon icon2 = fsv.getSystemIcon(new File("."), 32);
Will the resulted icons have proper size 16 and 32?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From serb at openjdk.java.net  Thu May 20 16:17:36 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 20 May 2021 16:17:36 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v10]
In-Reply-To: <6nuXr_47TELjEEJ0ECmiuPx7P-OLUH7otsUkckJldJ8=.08a2ea69-c9e0-4d76-8410-17500e7aa727@github.com>
References: 
 
 
 
 
 <7vA_X9_ewormZz-Iw8597kYrHT3MYorOUuNlGZQcRKY=.eef758f1-7d53-4085-916d-1f462d659346@github.com>
 <6nuXr_47TELjEEJ0ECmiuPx7P-OLUH7otsUkckJldJ8=.08a2ea69-c9e0-4d76-8410-17500e7aa727@github.com>
Message-ID: <9Ml44NxZ4rdQGlZY3ouRqN-o1z5XiC2wd86P07qutEM=.b3753433-a787-4350-afb1-3aef9ff8fb2c@github.com>

On Thu, 20 May 2021 14:55:06 GMT, Alexey Ivanov  wrote:

>> The CSR is already approved and changing specification at this point will require to roll it back to draft and then going trough the approval process again which in turn risks this change not to make it in the upcoming LTS release. I would prefer to integrate it and create a follow-up bug to clarify the wording where we can discuss the matter and - if it is worth it - to submit a new CSR to amend the specification.
>
> If *user coordinate system* is used in similar context in other methods, we should change the wording to match it. I don't mind using a new bug to clarify *virtual pixels*.
> 
> The term *user space* (coordinate system) is used in the majority of cases.

BTW this is why I recommended filing a CSR after the fix is fully discussed and agreed upon.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From serb at openjdk.java.net  Thu May 20 16:17:38 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 20 May 2021 16:17:38 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v10]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 20 May 2021 07:30:00 GMT, Alexander Zuev  wrote:

>> Fix updated after first round of review.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Empty 
 tag before @implSpec causes warning during javadoc generation

test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java line 27:

> 25:  * @test
> 26:  * @bug 8182043
> 27:  * @requires os.family == "windows"

Other than using "explorer" what prevents us to run this test on other platforms?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From kizune at openjdk.java.net  Thu May 20 16:48:33 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 20 May 2021 16:48:33 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v7]
In-Reply-To: <1WLwml_6PHy_gkPSSz18FpM8AEiFCVDGfR1S06ZxBGk=.b245e8e7-686c-4018-853b-984a35c1fecd@github.com>
References: 
 
 
 
 
 <1WLwml_6PHy_gkPSSz18FpM8AEiFCVDGfR1S06ZxBGk=.b245e8e7-686c-4018-853b-984a35c1fecd@github.com>
Message-ID: 

On Thu, 20 May 2021 16:06:37 GMT, Sergey Bylokhov  wrote:

>> Are we sure that all possible paths can be pointed by the file object? Especially some "Windows Libraries" which are accessed by the shell folder?
>
> Later we say that this method returns null for non-existed files. is it always correct? I am not sure that the file created for the library report true for the exists() method; DId we test this usecase?

We do not test for that in the regression test but i did tested it manually and we do return null for the non-existed files. I tested it on non-windows platform too. We still return null.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From kizune at openjdk.java.net  Thu May 20 16:48:34 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 20 May 2021 16:48:34 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v7]
In-Reply-To: 
References: 
 
 
 
 
 <1WLwml_6PHy_gkPSSz18FpM8AEiFCVDGfR1S06ZxBGk=.b245e8e7-686c-4018-853b-984a35c1fecd@github.com>
 
Message-ID: 

On Thu, 20 May 2021 16:43:05 GMT, Alexander Zuev  wrote:

>> Later we say that this method returns null for non-existed files. is it always correct? I am not sure that the file created for the library report true for the exists() method; DId we test this usecase?
>
> We do not test for that in the regression test but i did tested it manually and we do return null for the non-existed files. I tested it on non-windows platform too. We still return null.

> Are we sure that all possible paths can be pointed by the file object?

We specify that we return the icon for a file. If path can not be resolved in the file object we can not return the icon for it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From kizune at openjdk.java.net  Thu May 20 16:56:54 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 20 May 2021 16:56:54 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v10]
In-Reply-To: 
References: 
 
 
 
 
 
 
 
Message-ID: 

On Thu, 20 May 2021 16:13:41 GMT, Sergey Bylokhov  wrote:

>> My point was that the implspec is a normative specification and we cannot refer to non-public classes in that documentation.
>
> As for the example on Linux, how it will work for different sizes?
>    Icon icon1 = fsv.getSystemIcon(new File("."), 16);
>    Icon icon2 = fsv.getSystemIcon(new File("."), 32);
> Will the resulted icons have proper size 16 and 32?

No they will have the same size. That's why the broad wording is used that we take a requested size into consideration but we will return the best possible icon we can get and we do not guarantee that the icon size will change the outcome. Even on Windows if we request icon if sizes 1, 2, 3 and 4 the icon will be basically the same - minimal quality icon available.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From kizune at openjdk.java.net  Thu May 20 17:01:43 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 20 May 2021 17:01:43 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v10]
In-Reply-To: 
References: 
 
 
 
 
 
 
 
 
Message-ID: 

On Thu, 20 May 2021 16:53:06 GMT, Alexander Zuev  wrote:

>> As for the example on Linux, how it will work for different sizes?
>>    Icon icon1 = fsv.getSystemIcon(new File("."), 16);
>>    Icon icon2 = fsv.getSystemIcon(new File("."), 32);
>> Will the resulted icons have proper size 16 and 32?
>
> No they will have the same size. That's why the broad wording is used that we take a requested size into consideration but we will return the best possible icon we can get and we do not guarantee that the icon size will change the outcome. Even on Windows if we request icon if sizes 1, 2, 3 and 4 the icon will be basically the same - minimal quality icon available.

> My point was that the implspec is a normative specification and we cannot refer to non-public classes in that documentation.

implSpec may describe the behavior of the default implementation and if it means referring the non-public API to clarify the behavior of this method i do not see any issue here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From kizune at openjdk.java.net  Thu May 20 17:28:34 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 20 May 2021 17:28:34 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v10]
In-Reply-To: <9F_rdHvAvvU0lzKX0edszbTNSaSdc-VpLmaaV_SdzNE=.37c9c016-22e2-497f-b711-93f9a45db7f8@github.com>
References: 
 
 <9F_rdHvAvvU0lzKX0edszbTNSaSdc-VpLmaaV_SdzNE=.37c9c016-22e2-497f-b711-93f9a45db7f8@github.com>
Message-ID: 

On Thu, 20 May 2021 15:57:04 GMT, Sergey Bylokhov  wrote:

> This is to describe one of my questions above, is this instanceof+cast cannot be improved? Why we cannot always wrap the data in the MRI and if we have only one icon return the MRI with one resolution?

No because in specification we say that we do not guarantee the the icon returned will be MRI. We know how it works on Windows so we test it this way.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From serb at openjdk.java.net  Thu May 20 17:36:36 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 20 May 2021 17:36:36 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v10]
In-Reply-To: 
References: 
 
 
 
 
 
 
 
 
 
Message-ID: 

On Thu, 20 May 2021 16:58:36 GMT, Alexander Zuev  wrote:

>> No they will have the same size. That's why the broad wording is used that we take a requested size into consideration but we will return the best possible icon we can get and we do not guarantee that the icon size will change the outcome. Even on Windows if we request icon if sizes 1, 2, 3 and 4 the icon will be basically the same - minimal quality icon available.
>
>> My point was that the implspec is a normative specification and we cannot refer to non-public classes in that documentation.
> 
> implSpec may describe the behavior of the default implementation and if it means referring the non-public API to clarify the behavior of this method i do not see any issue here.

But it is still part of the specification unlike implnote/apinote, and we cannot use non-public classes there, since other JavaSE implementations may not have this class. see discussion on the link above.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From kizune at openjdk.java.net  Thu May 20 17:36:36 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 20 May 2021 17:36:36 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v10]
In-Reply-To: <9Ml44NxZ4rdQGlZY3ouRqN-o1z5XiC2wd86P07qutEM=.b3753433-a787-4350-afb1-3aef9ff8fb2c@github.com>
References: 
 
 
 
 
 <7vA_X9_ewormZz-Iw8597kYrHT3MYorOUuNlGZQcRKY=.eef758f1-7d53-4085-916d-1f462d659346@github.com>
 <6nuXr_47TELjEEJ0ECmiuPx7P-OLUH7otsUkckJldJ8=.08a2ea69-c9e0-4d76-8410-17500e7aa727@github.com>
 <9Ml44NxZ4rdQGlZY3ouRqN-o1z5XiC2wd86P07qutEM=.b3753433-a787-4350-afb1-3aef9ff8fb2c@github.com>
Message-ID: 

On Thu, 20 May 2021 16:14:42 GMT, Sergey Bylokhov  wrote:

> BTW this is why I recommended filing a CSR after the fix is fully discussed and agreed upon.

The CSR was filed almost five years ago.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From serb at openjdk.java.net  Thu May 20 17:36:37 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 20 May 2021 17:36:37 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v10]
In-Reply-To: 
References: 
 
 <9F_rdHvAvvU0lzKX0edszbTNSaSdc-VpLmaaV_SdzNE=.37c9c016-22e2-497f-b711-93f9a45db7f8@github.com>
 
Message-ID: 

On Thu, 20 May 2021 17:25:33 GMT, Alexander Zuev  wrote:

>> test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java line 72:
>> 
>>> 70:             if (icon.getImage() instanceof MultiResolutionImage) {
>>> 71:                 MultiResolutionImage mri = (MultiResolutionImage) icon.getImage();
>>> 72:                 if (mri.getResolutionVariant(size, size) == null) {
>> 
>> This is to describe one of my questions above, is this instanceof+cast cannot be improved? Why we cannot always wrap the data in the MRI and if we have only one icon return the MRI with one resolution?
>
>> This is to describe one of my questions above, is this instanceof+cast cannot be improved? Why we cannot always wrap the data in the MRI and if we have only one icon return the MRI with one resolution?
> 
> No because in specification we say that we do not guarantee the the icon returned will be MRI. We know how it works on Windows so we test it this way.

Here I am not talking about specification, I am talking about the usage of it, is the instanceof+cast is helpful? It does not look good, why we cannot always return MRI?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From serb at openjdk.java.net  Thu May 20 17:40:37 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 20 May 2021 17:40:37 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v7]
In-Reply-To: 
References: 
 
 
 
 
 <1WLwml_6PHy_gkPSSz18FpM8AEiFCVDGfR1S06ZxBGk=.b245e8e7-686c-4018-853b-984a35c1fecd@github.com>
 
 
Message-ID: 

On Thu, 20 May 2021 16:45:35 GMT, Alexander Zuev  wrote:

>> We do not test for that in the regression test but i did tested it manually and we do return null for the non-existed files. I tested it on non-windows platform too. We still return null.
>
>> Are we sure that all possible paths can be pointed by the file object?
> 
> We specify that we return the icon for a file. If path can not be resolved in the file object we can not return the icon for it.

So the libraries are not supported? I doubt since JFileChooser should support them, and supports of it is one of the reasons why we use shell folder to iterate the folders and do not use the javaio.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From kcr at openjdk.java.net  Thu May 20 18:31:33 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 20 May 2021 18:31:33 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
Message-ID: <58-JOVfSiUl3xFtcjGhwaviPqV-amDLlusvj_yCwmj8=.6d3bbada-4a59-443a-9940-121606b64a71@github.com>

On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang  wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

This isn't a review of the code changes, although I did take a quick look at the manual changes, and they look fine.

I did a local build of the PR branch on Windows, Mac, and Linux, and then did a build / test of JavaFX using that locally built JDK to find all the places where I need to add `-Djava.security.manager=allow` to the JavaFX tests to fix [JDK-8264140](https://bugs.openjdk.java.net/browse/JDK-8264140). It's working as expected.

-------------

Marked as reviewed by kcr (Author).

PR: https://git.openjdk.java.net/jdk/pull/4073

From kizune at openjdk.java.net  Thu May 20 18:54:40 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 20 May 2021 18:54:40 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v10]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 20 May 2021 16:09:14 GMT, Sergey Bylokhov  wrote:

> Other than using "explorer" what prevents us to run this test on other platforms?

Because right now it makes no sense? The functionality we are testing is implemented on Windows only. Once we extend it to other platforms we might change the test.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From aivanov at openjdk.java.net  Thu May 20 18:54:39 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 20 May 2021 18:54:39 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v7]
In-Reply-To: 
References: 
 
 
 
 
 <1WLwml_6PHy_gkPSSz18FpM8AEiFCVDGfR1S06ZxBGk=.b245e8e7-686c-4018-853b-984a35c1fecd@github.com>
 
 
 
Message-ID: 

On Thu, 20 May 2021 17:37:20 GMT, Sergey Bylokhov  wrote:

>>> Are we sure that all possible paths can be pointed by the file object?
>> 
>> We specify that we return the icon for a file. If path can not be resolved in the file object we can not return the icon for it.
>
> So the libraries are not supported? I doubt since JFileChooser should support them, and supports of it is one of the reasons why we use shell folder to iterate the folders and do not use the javaio.

No, libraries are not supported.

I see no contradiction here: `JFileChooser` uses Windows Shell API to enumerate objects and navigate the shell namespace. But it does not return non-file objects, does it?

The new method accepts `File` object which implies it's a file system object rather than an arbitrary object in Windows Shell namespace which cannot be represented in Java.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From kizune at openjdk.java.net  Thu May 20 19:25:36 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 20 May 2021 19:25:36 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v10]
In-Reply-To: 
References: 
 
 
 
 
 
 
 
 
 
 
Message-ID: 

On Thu, 20 May 2021 17:33:08 GMT, Sergey Bylokhov  wrote:

> But it is still part of the specification unlike implnote/apinote

I think you can suggest usage of the implNote here - i am going from the initial description of the reason implSpec in the JEP saying that implementation and logic of it may vary between different Java SE implementations and even between different platforms so i am going with the original reasoning for implSpec tag existence. If you disagree, please file the separate issue for spec amendment once this PR is integrated. Or we can discuss it and i file follow-up bug - whatever you prefer, but i honestly think it is not a blocker and that this technical issue linger in this state for way too long.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From kizune at openjdk.java.net  Thu May 20 19:28:50 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 20 May 2021 19:28:50 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v10]
In-Reply-To: 
References: 
 
 <9F_rdHvAvvU0lzKX0edszbTNSaSdc-VpLmaaV_SdzNE=.37c9c016-22e2-497f-b711-93f9a45db7f8@github.com>
 
 
Message-ID: 

On Thu, 20 May 2021 17:29:55 GMT, Sergey Bylokhov  wrote:

> Here I am not talking about specification, I am talking about the usage of it, is the instanceof+cast is helpful?

It is necessary until all the consequences of always returning of MRI is extensively tested on all the supported platforms and it does not cause any serious regression or visual degradations. So for now i would not enforce MRI usage in this method which means use base image class instead and do the cast later.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From prr at openjdk.java.net  Thu May 20 19:38:36 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 20 May 2021 19:38:36 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v10]
In-Reply-To: 
References: 
 
 
 
 
 
 
 
 
 
 
 
Message-ID: 

On Thu, 20 May 2021 19:22:50 GMT, Alexander Zuev  wrote:

>> But it is still part of the specification unlike implnote/apinote, and we cannot use non-public classes there, since other JavaSE implementations may not have this class. see discussion on the link above.
>
>> But it is still part of the specification unlike implnote/apinote
> 
> I think you can suggest usage of the implNote here - i am going from the initial description of the reason implSpec in the JEP saying that implementation and logic of it may vary between different Java SE implementations and even between different platforms so i am going with the original reasoning for implSpec tag existence. If you disagree, please file the separate issue for spec amendment once this PR is integrated. Or we can discuss it and i file follow-up bug - whatever you prefer, but i honestly think it is not a blocker and that this technical issue linger in this state for way too long.

We absolutely should NOT reference a non-API class in the public javadoc, no matter whether
it is an implNote or implSpec. 
Additionally, if you add or remove an implNote or implSpec or update it for something much more than a typo you will need to revise the CSR.

Really I would need to see what the actual delta ends up being to be sure for this case.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From kizune at openjdk.java.net  Thu May 20 22:25:05 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 20 May 2021 22:25:05 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v11]
In-Reply-To: 
References: 
Message-ID: 

> Fix updated after first round of review.

Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:

  Specification of getSystemIcon reworded to get rid of the non-public
  class reference and to better describe some cornor cases

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2875/files
  - new: https://git.openjdk.java.net/jdk/pull/2875/files/09c7f8d7..548dcef1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2875&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2875&range=09-10

  Stats: 11 lines in 1 file changed: 5 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2875.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2875/head:pull/2875

PR: https://git.openjdk.java.net/jdk/pull/2875

From kizune at openjdk.java.net  Thu May 20 22:28:36 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 20 May 2021 22:28:36 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v10]
In-Reply-To: 
References: 
 
 
 
 
 
 
 
 
 
 
 
 
Message-ID: 

On Thu, 20 May 2021 19:35:57 GMT, Phil Race  wrote:

> Really I would need to see what the actual delta ends up being to be sure for this case.

I have updated the method documentation. Could you please take a look before i finalized the CSR again? I am really trying to push this functionality into 17 and there's not much time left. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From serb at openjdk.java.net  Thu May 20 22:41:51 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 20 May 2021 22:41:51 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v10]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Thu, 20 May 2021 18:49:53 GMT, Alexander Zuev  wrote:

>> test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java line 27:
>> 
>>> 25:  * @test
>>> 26:  * @bug 8182043
>>> 27:  * @requires os.family == "windows"
>> 
>> Other than using "explorer" what prevents us to run this test on other platforms?
>
>> Other than using "explorer" what prevents us to run this test on other platforms?
> 
> Because right now it makes no sense? The functionality we are testing is implemented on Windows only. Once we extend it to other platforms we might change the test.

But this is shared code, which has a specification it should work everywhere, so even if on Linux and macOS it is not implemented in the best way it should return something.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From serb at openjdk.java.net  Thu May 20 22:41:51 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 20 May 2021 22:41:51 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v10]
In-Reply-To: 
References: 
 
 <9F_rdHvAvvU0lzKX0edszbTNSaSdc-VpLmaaV_SdzNE=.37c9c016-22e2-497f-b711-93f9a45db7f8@github.com>
 
 
 
Message-ID: 

On Thu, 20 May 2021 19:25:38 GMT, Alexander Zuev  wrote:

>> Here I am not talking about specification, I am talking about the usage of it, is the instanceof+cast is helpful? It does not look good, why we cannot always return MRI?
>
>> Here I am not talking about specification, I am talking about the usage of it, is the instanceof+cast is helpful?
> 
> It is necessary until all the consequences of always returning of MRI is extensively tested on all the supported platforms and it does not cause any serious regression or visual degradations. So for now i would not enforce MRI usage in this method which means use base image class instead and do the cast later.

I did not get how you will be able to force use MRI later since this method is implemented as a return icon. So this choice should be made before integration.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From kizune at openjdk.java.net  Thu May 20 23:02:41 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 20 May 2021 23:02:41 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v10]
In-Reply-To: 
References: 
 
 <9F_rdHvAvvU0lzKX0edszbTNSaSdc-VpLmaaV_SdzNE=.37c9c016-22e2-497f-b711-93f9a45db7f8@github.com>
 
 
 
 
Message-ID: 

On Thu, 20 May 2021 22:37:08 GMT, Sergey Bylokhov  wrote:

> I did not get how you will be able to force use MRI later since this method is implemented as a return icon. So this choice should be made before integration.

I am not going to force MRI usage - i am assuming that there might be an implementation that does not do it hence i am going to go to the lowest common denominator - Icon.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From kizune at openjdk.java.net  Thu May 20 23:05:33 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 20 May 2021 23:05:33 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v10]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Thu, 20 May 2021 22:38:48 GMT, Sergey Bylokhov  wrote:

> But this is shared code, which has a specification it should work everywhere, so even if on Linux and macOS it is not implemented in the best way it should return something.

The stuff that is returned by the common code is already tested in UIManager tests. This issue is windows specific. This implementation at this moment of time is windows specific. Once we extend implementation - and i mean real implementation with support for multiple resolution icons - this test will be updated to reflect it. This is not a specification conformance test, it is implementation logic test.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From serb at openjdk.java.net  Fri May 21 01:25:36 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 21 May 2021 01:25:36 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v10]
In-Reply-To: 
References: 
 
 <9F_rdHvAvvU0lzKX0edszbTNSaSdc-VpLmaaV_SdzNE=.37c9c016-22e2-497f-b711-93f9a45db7f8@github.com>
 
 
 
 
 
Message-ID: 

On Thu, 20 May 2021 22:59:43 GMT, Alexander Zuev  wrote:

>> I did not get how you will be able to force use MRI later since this method is implemented as a return icon. So this choice should be made before integration.
>
>> I did not get how you will be able to force use MRI later since this method is implemented as a return icon. So this choice should be made before integration.
> 
> I am not going to force MRI usage - i am assuming that there might be an implementation that does not do it hence i am going to go to the lowest common denominator - Icon.

But in the code above you do not use the icon, you use an ImageIcon. So to get the resolution variant the user need to do something like:

    Icon icon = fsv.getSystemIcon(file, size);
    if (icon instanceof ImageIcon) {
        ImageIcon imageIcon = (ImageIcon) icon;
        if (icon.getImage() instanceof MultiResolutionImage) {
            MultiResolutionImage mri = (MultiResolutionImage) icon.getImage();
            .... = mri.getResolutionVariant(size, size);
        }
    }

Probably some other variants were discussed already and we cannot do something better?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From serb at openjdk.java.net  Fri May 21 01:25:35 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 21 May 2021 01:25:35 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v10]
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: <4uB4NmYhMOygdUQ5Pmiwzl8o7Hg69PPVsI82XboqvGI=.b3bd9188-5e17-4cba-8837-0dce3aa16c29@github.com>

On Thu, 20 May 2021 23:03:02 GMT, Alexander Zuev  wrote:

>> But this is shared code, which has a specification it should work everywhere, so even if on Linux and macOS it is not implemented in the best way it should return something.
>
>> But this is shared code, which has a specification it should work everywhere, so even if on Linux and macOS it is not implemented in the best way it should return something.
> 
> The stuff that is returned by the common code is already tested in UIManager tests. This issue is windows specific. This implementation at this moment of time is windows specific. Once we extend implementation - and i mean real implementation with support for multiple resolution icons - this test will be updated to reflect it. This is not a specification conformance test, it is implementation logic test.

How it could be tested by the UIManager tests since this is a new method added in this class? I guess it should work just out of the box, no? What is the reason to not enable it, there are some issues?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From weijun at openjdk.java.net  Fri May 21 01:58:47 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 01:58:47 GMT
Subject:  RFR: 8267521: Post JEP 411 refactoring: maximum
 covering > 50K
Message-ID: 

The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed.

-------------

Depends on: https://git.openjdk.java.net/jdk/pull/4073

Commit messages:
 - 8267521: Post JEP 411 refactoring: maximum covering > 50K

Changes: https://git.openjdk.java.net/jdk/pull/4138/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4138&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267521
  Stats: 226 lines in 18 files changed: 142 ins; 29 del; 55 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4138.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4138/head:pull/4138

PR: https://git.openjdk.java.net/jdk/pull/4138

From serb at openjdk.java.net  Fri May 21 02:48:36 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 21 May 2021 02:48:36 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v7]
In-Reply-To: 
References: 
 
 
 
 
 <1WLwml_6PHy_gkPSSz18FpM8AEiFCVDGfR1S06ZxBGk=.b245e8e7-686c-4018-853b-984a35c1fecd@github.com>
 
 
 
 
Message-ID: 

On Thu, 20 May 2021 18:51:54 GMT, Alexey Ivanov  wrote:

>> So the libraries are not supported? I doubt since JFileChooser should support them, and supports of it is one of the reasons why we use shell folder to iterate the folders and do not use the javaio.
>
> No, libraries are not supported.
> 
> I see no contradiction here: `JFileChooser` uses Windows Shell API to enumerate objects and navigate the shell namespace. But it does not return non-file objects, does it?
> 
> The new method accepts `File` object which implies it's a file system object rather than an arbitrary object in Windows Shell namespace which cannot be represented in Java.

The JFileChooser supports the libraries since it allows navigation inside them. It is done via ShellFolder which extends the file class. The FileSystemView feeds the JFileChooser by the data, so it may returns "non-file" objects.
For example the FileSystemView.getRoots() on WIndows will return "new Win32ShellFolder2(DESKTOP)".

Usually, when the FileSystemView gets a file object it checks that the file is "instance ShellFolder".
For example, in the newly added method the line "sf = ShellFolder.getShellFolder(f);" will check that the file is ShellFolder and return it as-is without checking of file existence, and really that path may not exist. but if it is a plain file it will check that.

This is why I have asked about virtual folders, do we test them or we can consider them as "not existed"?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From serb at openjdk.java.net  Fri May 21 03:24:39 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 21 May 2021 03:24:39 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v7]
In-Reply-To: 
References: 
 
 
 
 
 <1WLwml_6PHy_gkPSSz18FpM8AEiFCVDGfR1S06ZxBGk=.b245e8e7-686c-4018-853b-984a35c1fecd@github.com>
 
 
 
 
 
Message-ID: <1sysgP9ZDpZR3PBvXHWLCo8FU87rEFSvya58vutrmcQ=.22f273a3-d740-4e7c-ad37-e9c128fdb5df@github.com>

On Fri, 21 May 2021 02:45:15 GMT, Sergey Bylokhov  wrote:

>> No, libraries are not supported.
>> 
>> I see no contradiction here: `JFileChooser` uses Windows Shell API to enumerate objects and navigate the shell namespace. But it does not return non-file objects, does it?
>> 
>> The new method accepts `File` object which implies it's a file system object rather than an arbitrary object in Windows Shell namespace which cannot be represented in Java.
>
> The JFileChooser supports the libraries since it allows navigation inside them. It is done via ShellFolder which extends the file class. The FileSystemView feeds the JFileChooser by the data, so it may returns "non-file" objects.
> For example the FileSystemView.getRoots() on WIndows will return "new Win32ShellFolder2(DESKTOP)".
> 
> Usually, when the FileSystemView gets a file object it checks that the file is "instance ShellFolder".
> For example, in the newly added method the line "sf = ShellFolder.getShellFolder(f);" will check that the file is ShellFolder and return it as-is without checking of file existence, and really that path may not exist. but if it is a plain file it will check that.
> 
> This is why I have asked about virtual folders, do we test them or we can consider them as "not existed"?

Maybe we can test this case by just reusing this method where the "sf.getIcon(largeicon)" previously used in the WindowsPlacesBar class? That old method has the special code for "folder.isLibrary()" so I assume it supported the Libraries. And if we will start to use the new method then all old tests for the JFileChooser will start to test it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From kizune at openjdk.java.net  Fri May 21 04:18:41 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 21 May 2021 04:18:41 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v7]
In-Reply-To: <1sysgP9ZDpZR3PBvXHWLCo8FU87rEFSvya58vutrmcQ=.22f273a3-d740-4e7c-ad37-e9c128fdb5df@github.com>
References: 
 
 
 
 
 <1WLwml_6PHy_gkPSSz18FpM8AEiFCVDGfR1S06ZxBGk=.b245e8e7-686c-4018-853b-984a35c1fecd@github.com>
 
 
 
 
 
 <1sysgP9ZDpZR3PBvXHWLCo8FU87rEFSvya58vutrmcQ=.22f273a3-d740-4e7c-ad37-e9c128fdb5df@github.com>
Message-ID: <5JM-jypDvy8tIap4gepmRg5kRJkRj7qfPkFl3ATCMps=.491aa8f2-0ee3-4541-a10b-5b9b26c0bcf2@github.com>

On Fri, 21 May 2021 03:21:19 GMT, Sergey Bylokhov  wrote:

>> The JFileChooser supports the libraries since it allows navigation inside them. It is done via ShellFolder which extends the file class. The FileSystemView feeds the JFileChooser by the data, so it may returns "non-file" objects.
>> For example the FileSystemView.getRoots() on WIndows will return "new Win32ShellFolder2(DESKTOP)".
>> 
>> Usually, when the FileSystemView gets a file object it checks that the file is "instance ShellFolder".
>> For example, in the newly added method the line "sf = ShellFolder.getShellFolder(f);" will check that the file is ShellFolder and return it as-is without checking of file existence, and really that path may not exist. but if it is a plain file it will check that.
>> 
>> This is why I have asked about virtual folders, do we test them or we can consider them as "not existed"?
>
> Maybe we can test this case by just reusing this method where the "sf.getIcon(largeicon)" previously used in the WindowsPlacesBar class? That old method has the special code for "folder.isLibrary()" so I assume it supported the Libraries. And if we will start to use the new method then all old tests for the JFileChooser will start to test it.

What is the library a collection folder such as Recent Items or Documents?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From serb at openjdk.java.net  Fri May 21 05:45:32 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 21 May 2021 05:45:32 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v7]
In-Reply-To: <5JM-jypDvy8tIap4gepmRg5kRJkRj7qfPkFl3ATCMps=.491aa8f2-0ee3-4541-a10b-5b9b26c0bcf2@github.com>
References: 
 
 
 
 
 <1WLwml_6PHy_gkPSSz18FpM8AEiFCVDGfR1S06ZxBGk=.b245e8e7-686c-4018-853b-984a35c1fecd@github.com>
 
 
 
 
 
 <1sysgP9ZDpZR3PBvXHWLCo8FU87rEFSvya58vutrmcQ=.22f273a3-d740-4e7c-ad37-e9c128fdb5df@github.com>
 <5JM-jypDvy8tIap4gepmRg5kRJkRj7qfPkFl3ATCMps=.491aa8f2-0ee3-4541-a10b-5b9b26c0bcf2@github.com>
Message-ID: 

On Fri, 21 May 2021 04:15:41 GMT, Alexander Zuev  wrote:

>> Maybe we can test this case by just reusing this method where the "sf.getIcon(largeicon)" previously used in the WindowsPlacesBar class? That old method has the special code for "folder.isLibrary()" so I assume it supported the Libraries. And if we will start to use the new method then all old tests for the JFileChooser will start to test it.
>
> What is the library a collection folder such as Recent Items or Documents?

It is accessible from the "JFileChooser" drop-down menu. On my system, the Libraries at that drop down menu contain "GIT", "Documents", "Music". https://docs.microsoft.com/en-us/windows/client-management/windows-libraries

There are also "known folders" such as "Network" or "My computer" which do not have a real path but can be navigated in the JFileChooser and has an icon.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From kizune at openjdk.java.net  Fri May 21 06:34:43 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 21 May 2021 06:34:43 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v7]
In-Reply-To: 
References: 
 
 
 
 
 <1WLwml_6PHy_gkPSSz18FpM8AEiFCVDGfR1S06ZxBGk=.b245e8e7-686c-4018-853b-984a35c1fecd@github.com>
 
 
 
 
 
 <1sysgP9ZDpZR3PBvXHWLCo8FU87rEFSvya58vutrmcQ=.22f273a3-d740-4e7c-ad37-e9c128fdb5df@github.com>
 <5JM-jypDvy8tIap4gepmRg5kRJkRj7qfPkFl3ATCMps=.491aa8f2-0ee3-4541-a10b-5b9b26c0bcf2@github.com>
 
Message-ID: <23JNwdRJ_IfCF2uO6fwuvlCBvYzcymPQwgylxg2KZDA=.b37c4b73-415d-4b31-876f-98dbfac7e89c@github.com>

On Fri, 21 May 2021 05:42:46 GMT, Sergey Bylokhov  wrote:

> It is accessible from the "JFileChooser" drop-down menu. On my system, the Libraries at that drop down menu contain "GIT", "Documents", "Music". https://docs.microsoft.com/en-us/windows/client-management/windows-libraries
> 
> There are also "known folders" such as "Network" or "My computer" which do not have a real path but can be navigated in the JFileChooser and has an icon.

Ok, got it. Well, since they can be translated into the file system paths - even if these paths do not belong to physical filesystem - they are supported by the new API. Not for all of them i am able to receive the high resolution icons - like "Recent Items" for some reason only provides 32x32 and 16x16 no matter what size i am asking for. Others such as Documents, My Computer or 3D Objects do provide all resolutions available. For example here's the screenshot of all the available icons for 3D Objects 
![image](https://user-images.githubusercontent.com/69642324/119092517-62a9f980-b9c3-11eb-9d51-b7745cab564c.png)

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From psadhukhan at openjdk.java.net  Fri May 21 09:41:36 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 21 May 2021 09:41:36 GMT
Subject:  Integrated: 8264218: Public method
 javax.swing.JMenu.setComponentOrientation() has no spec
In-Reply-To: 
References: 
Message-ID: <-jcNFUHUug68XfDdQ1octi7ygzWESkVJ7dYjsfxfGH0=.e5c2e5ad-fa05-4844-937c-45197b0ca4e5@github.com>

On Fri, 26 Mar 2021 11:30:35 GMT, Prasanta Sadhukhan  wrote:

> A public overriding method JMenu.setComponentOrientation(java.awt.ComponentOrientation)
> has no spec.
> Added spec for the method.

This pull request has now been integrated.

Changeset: e48d7d66
Author:    Prasanta Sadhukhan 
URL:       https://git.openjdk.java.net/jdk/commit/e48d7d66582d9c9630d85e86ff344794656914fc
Stats:     7 lines in 1 file changed: 7 ins; 0 del; 0 mod

8264218: Public method javax.swing.JMenu.setComponentOrientation() has no spec

Reviewed-by: aivanov

-------------

PR: https://git.openjdk.java.net/jdk/pull/3213

From weijun at openjdk.java.net  Fri May 21 14:00:39 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 14:00:39 GMT
Subject:  RFR: 8267521: Post JEP 411 refactoring: maximum
 covering > 50K [v2]
In-Reply-To: 
References: 
Message-ID: 

> The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed.
> 
> The code change shows some common solutions to avoid such too wide annotations:
> 
> 1. Extract calls into a method and add annotation on that method
> 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value.
> 3. Put declaration and assignment into a single statement if possible.
> 4. Rewrite code to achieve #3 above.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  typo on windows

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4138/files
  - new: https://git.openjdk.java.net/jdk/pull/4138/files/e3f0405a..d460efb8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4138&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4138&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4138.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4138/head:pull/4138

PR: https://git.openjdk.java.net/jdk/pull/4138

From dfuchs at openjdk.java.net  Fri May 21 15:36:08 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 21 May 2021 15:36:08 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
Message-ID: 

On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang  wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

src/java.base/share/classes/java/lang/SecurityManager.java line 104:

> 102:  * method will throw an {@code UnsupportedOperationException}). If the
> 103:  * {@systemProperty java.security.manager} system property is set to the
> 104:  * special token "{@code allow}", then a security manager will not be set at

Can/should the `{@systemProperty ...}` tag be used more than once for a given system property? I thought it should be used only once, at the place where the system property is defined. Maybe @jonathan-gibbons can offer some more guidance on this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From dfuchs at openjdk.java.net  Fri May 21 15:55:07 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 21 May 2021 15:55:07 GMT
Subject:  RFR: 8267521: Post JEP 411 refactoring: maximum
 covering > 50K [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 21 May 2021 14:00:39 GMT, Weijun Wang  wrote:

>> The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed.
>> 
>> The code change shows some common solutions to avoid such too wide annotations:
>> 
>> 1. Extract calls into a method and add annotation on that method
>> 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value.
>> 3. Put declaration and assignment into a single statement if possible.
>> 4. Rewrite code to achieve #3 above.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo on windows

src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java line 120:

> 118:                         vals[1] = Integer.getInteger("sun.net.client.defaultConnectTimeout", 300_000).intValue();
> 119:                         return System.getProperty("file.encoding", "ISO8859_1");
> 120:                     }

It is a bit strange that "file.encoding" seem to get a special treatment - but I guess that's OK.

src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java line 550:

> 548:      * @throws IOException if the connection was unsuccessful.
> 549:      */
> 550:     @SuppressWarnings("removal")

Could the scope of the annotation be further reduced by applying it to the two places where `doPrivileged` is called in this method?

src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java line 921:

> 919:     }
> 920: 
> 921:     @SuppressWarnings("removal")

Could the scope be further reduced by applying it at line 926 in this method - at the cost of creating a temporary variable? The code could probably be further simplified by using a lambda...


            PrivilegedAction pa = () -> new Socket(proxy);
            @SuppressWarnings("removal")
            var ps = AccessController.doPrivileged(pa);
            s = ps;

-------------

PR: https://git.openjdk.java.net/jdk/pull/4138

From prr at openjdk.java.net  Fri May 21 18:03:01 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 21 May 2021 18:03:01 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 
 
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 
 
 
 <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com>
 
 
Message-ID: 

On Thu, 20 May 2021 07:06:00 GMT, Alan Bateman  wrote:

>> The JEP isn't PTT for 17 so there's plenty of time isn't there ?
>
> There are 827 files in this patch. Phil is right that adding SW at the class level is introducing technical debt but if addressing that requires refactoring and re-testing of AWT or font code then it would be better to have someone from that area working on. Is there any reason why this can't be going on now on awt-dev/2d-dev and integrated immediately after JEP 411? I don't think we should put Max through the wringer here as there are too many areas to cover.

Are you suggesting that the patch doesn't need testing as it is ? It should be the same either way.
It is very straight forward to run the automated tests across all platforms these days.
I get the impression that no one is guaranteeing to do this straight after integration.
It sounds like it is up for deferral if time runs out.

The amount of follow-on work that I am hearing about here, and may be for tests, does not  make it sound
like this JEP is nearly as done as first presented.

If there was some expectation that groups responsible for an area would get involved with this
issue which I am assured was already known about, then why was it not raised before and made
part of the plan ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From serb at openjdk.java.net  Fri May 21 18:21:14 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 21 May 2021 18:21:14 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v7]
In-Reply-To: <23JNwdRJ_IfCF2uO6fwuvlCBvYzcymPQwgylxg2KZDA=.b37c4b73-415d-4b31-876f-98dbfac7e89c@github.com>
References: 
 
 
 
 
 <1WLwml_6PHy_gkPSSz18FpM8AEiFCVDGfR1S06ZxBGk=.b245e8e7-686c-4018-853b-984a35c1fecd@github.com>
 
 
 
 
 
 <1sysgP9ZDpZR3PBvXHWLCo8FU87rEFSvya58vutrmcQ=.22f273a3-d740-4e7c-ad37-e9c128fdb5df@github.com>
 <5JM-jypDvy8tIap4gepmRg5kRJkRj7qfPkFl3ATCMps=.491aa8f2-0ee3-4541-a10b-5b9b26c0bcf2@github.com>
 
 <23JNwdRJ_IfCF2uO6fwuvlCBvYzcymPQwgylxg2KZDA=.b37c4b73-415d-4b31-876f-98dbfac7e89c@github.com>
Message-ID: 

On Fri, 21 May 2021 06:32:02 GMT, Alexander Zuev  wrote:

>> It is accessible from the "JFileChooser" drop-down menu. On my system, the Libraries at that drop down menu contain "GIT", "Documents", "Music". https://docs.microsoft.com/en-us/windows/client-management/windows-libraries
>> 
>> There are also "known folders" such as "Network" or "My computer" which do not have a real path but can be navigated in the JFileChooser and has an icon.
>
>> It is accessible from the "JFileChooser" drop-down menu. On my system, the Libraries at that drop down menu contain "GIT", "Documents", "Music". https://docs.microsoft.com/en-us/windows/client-management/windows-libraries
>> 
>> There are also "known folders" such as "Network" or "My computer" which do not have a real path but can be navigated in the JFileChooser and has an icon.
> 
> Ok, got it. Well, since they can be translated into the file system paths - even if these paths do not belong to physical filesystem - they are supported by the new API. Not for all of them i am able to receive the high resolution icons - like "Recent Items" for some reason only provides 32x32 and 16x16 no matter what size i am asking for. Others such as Documents, My Computer or 3D Objects do provide all resolutions available. For example here's the screenshot of all the available icons for 3D Objects 
> ![image](https://user-images.githubusercontent.com/69642324/119092517-62a9f980-b9c3-11eb-9d51-b7745cab564c.png)

But how you got them via this method? I am not sure what parameters should be passed to it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From serb at openjdk.java.net  Fri May 21 18:21:14 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 21 May 2021 18:21:14 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v10]
In-Reply-To: <4uB4NmYhMOygdUQ5Pmiwzl8o7Hg69PPVsI82XboqvGI=.b3bd9188-5e17-4cba-8837-0dce3aa16c29@github.com>
References: 
 
 
 
 
 
 <4uB4NmYhMOygdUQ5Pmiwzl8o7Hg69PPVsI82XboqvGI=.b3bd9188-5e17-4cba-8837-0dce3aa16c29@github.com>
Message-ID: <2O2oRd_8z73RslE49Ux-W1K-RdiSdYeIPyxkK-VePEM=.e040bcf9-c3d1-4b51-bcf3-fb5d7981ccbb@github.com>

On Fri, 21 May 2021 01:11:38 GMT, Sergey Bylokhov  wrote:

>>> But this is shared code, which has a specification it should work everywhere, so even if on Linux and macOS it is not implemented in the best way it should return something.
>> 
>> The stuff that is returned by the common code is already tested in UIManager tests. This issue is windows specific. This implementation at this moment of time is windows specific. Once we extend implementation - and i mean real implementation with support for multiple resolution icons - this test will be updated to reflect it. This is not a specification conformance test, it is implementation logic test.
>
> How it could be tested by the UIManager tests since this is a new method added in this class? I guess it should work just out of the box, no? What is the reason to not enable it, there are some issues?

I suggest running it now and do not wait while the new tck tests will be created and run, so we will not get a tck-red right before release.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From prr at openjdk.java.net  Fri May 21 18:31:01 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 21 May 2021 18:31:01 GMT
Subject:  RFR: 8267184: JEP 411: Add
 -Djava.security.manager=allow to tests calling System.setSecurityManager
 [v2]
In-Reply-To: 
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
 
Message-ID: <4w0JvyhZ5Kx5a_qqKvyBYBOw0thtX4_wBTtk1bDgsfw=.1665918a-092c-4b7e-a48e-5fc9810b9e0b@github.com>

On Tue, 18 May 2021 21:44:43 GMT, Weijun Wang  wrote:

>> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
>> 
>> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
>> 
>> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
>> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
>> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
>> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
>> 
>> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
>> 
>> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
>> 
>> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
>> 
>> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
>> 
>> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
>> 
>> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
>> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>>  ```
>> 
>> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust order of VM options

The client changes are fine except for the one misplaced (c)

test/jdk/java/awt/FontClass/CreateFont/fileaccess/FontFile.java line 3:

> 1: /*
> 2:  * Copyright (c) 2008, 2021, Oracle and/or its affiliates. All rights reserved.
> 3:  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

Probably the (c) update was meant to be on the .sh file that is actually modified.

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4071

From aivanov at openjdk.java.net  Fri May 21 19:15:04 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 21 May 2021 19:15:04 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v7]
In-Reply-To: 
References: 
 
 
 
 
 <1WLwml_6PHy_gkPSSz18FpM8AEiFCVDGfR1S06ZxBGk=.b245e8e7-686c-4018-853b-984a35c1fecd@github.com>
 
 
 
 
 
 <1sysgP9ZDpZR3PBvXHWLCo8FU87rEFSvya58vutrmcQ=.22f273a3-d740-4e7c-ad37-e9c128fdb5df@github.com>
 <5JM-jypDvy8tIap4gepmRg5kRJkRj7qfPkFl3ATCMps=.491aa8f2-0ee3-4541-a10b-5b9b26c0bcf2@github.com>
 
 <23JNwdRJ_IfCF2uO6fwuvlCBvYzcymPQwgylxg2KZDA=.b37c4b73-415d-4b31-876f-98dbfac7e89c@github.com>
 
Message-ID: 

On Fri, 21 May 2021 18:16:36 GMT, Sergey Bylokhov  wrote:

>>> It is accessible from the "JFileChooser" drop-down menu. On my system, the Libraries at that drop down menu contain "GIT", "Documents", "Music". https://docs.microsoft.com/en-us/windows/client-management/windows-libraries
>>> 
>>> There are also "known folders" such as "Network" or "My computer" which do not have a real path but can be navigated in the JFileChooser and has an icon.
>> 
>> Ok, got it. Well, since they can be translated into the file system paths - even if these paths do not belong to physical filesystem - they are supported by the new API. Not for all of them i am able to receive the high resolution icons - like "Recent Items" for some reason only provides 32x32 and 16x16 no matter what size i am asking for. Others such as Documents, My Computer or 3D Objects do provide all resolutions available. For example here's the screenshot of all the available icons for 3D Objects 
>> ![image](https://user-images.githubusercontent.com/69642324/119092517-62a9f980-b9c3-11eb-9d51-b7745cab564c.png)
>
> But how you got them via this method? I am not sure what parameters should be passed to it.

Didn't you answer your question already? If `FileSystemView.getRoots()` returns Desktop in Windows shell namespace. Otherwise, I don't know a way to get a reference to a *virtual* folder in Windows shell namespace which doesn't reference a file system object.

Alex's example uses "3D Objects" folder which is one of the known folders and has its own icon instead of the standard folder icon.

It's possible that I don't understand the question clearly.

Alex's fix affects WindowsPlacesBar on the left of JFileChooser in Windows LaF, the icons there look crispier in High DPI environment.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From kizune at openjdk.java.net  Fri May 21 19:40:08 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 21 May 2021 19:40:08 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v7]
In-Reply-To: 
References: 
 
 
 
 
 <1WLwml_6PHy_gkPSSz18FpM8AEiFCVDGfR1S06ZxBGk=.b245e8e7-686c-4018-853b-984a35c1fecd@github.com>
 
 
 
 
 
 <1sysgP9ZDpZR3PBvXHWLCo8FU87rEFSvya58vutrmcQ=.22f273a3-d740-4e7c-ad37-e9c128fdb5df@github.com>
 <5JM-jypDvy8tIap4gepmRg5kRJkRj7qfPkFl3ATCMps=.491aa8f2-0ee3-4541-a10b-5b9b26c0bcf2@github.com>
 
 <23JNwdRJ_IfCF2uO6fwuvlCBvYzcymPQwgylxg2KZDA=.b37c4b73-415d-4b31-876f-98dbfac7e89c@github.com>
 
 
Message-ID: 

On Fri, 21 May 2021 19:11:45 GMT, Alexey Ivanov  wrote:

>> But how you got them via this method? I am not sure what parameters should be passed to it.
>
> Didn't you answer your question already? If `FileSystemView.getRoots()` returns Desktop in Windows shell namespace. Otherwise, I don't know a way to get a reference to a *virtual* folder in Windows shell namespace which doesn't reference a file system object.
> 
> Alex's example uses "3D Objects" folder which is one of the known folders and has its own icon instead of the standard folder icon.
> 
> It's possible that I don't understand the question clearly.
> 
> Alex's fix affects WindowsPlacesBar on the left of JFileChooser in Windows LaF, the icons there look crispier in High DPI environment.

> But how you got them via this method? I am not sure what parameters should be passed to it.
`
String userdir = System.getenv("userprofile");
Icon icon = FileSystemView.getFileSystemView().getSystemIcon(new File(userdir + "\\3D Objects"), 64);
`

For some of the libraries getting file reference is quite easy, for some - not so much. But still doable.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From weijun at openjdk.java.net  Fri May 21 19:50:15 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 19:50:15 GMT
Subject:  RFR: 8267184: JEP 411: Add
 -Djava.security.manager=allow to tests calling System.setSecurityManager
 [v2]
In-Reply-To: <4w0JvyhZ5Kx5a_qqKvyBYBOw0thtX4_wBTtk1bDgsfw=.1665918a-092c-4b7e-a48e-5fc9810b9e0b@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
 
 <4w0JvyhZ5Kx5a_qqKvyBYBOw0thtX4_wBTtk1bDgsfw=.1665918a-092c-4b7e-a48e-5fc9810b9e0b@github.com>
Message-ID: 

On Fri, 21 May 2021 18:26:48 GMT, Phil Race  wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   adjust order of VM options
>
> test/jdk/java/awt/FontClass/CreateFont/fileaccess/FontFile.java line 3:
> 
>> 1: /*
>> 2:  * Copyright (c) 2008, 2021, Oracle and/or its affiliates. All rights reserved.
>> 3:  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> 
> Probably the (c) update was meant to be on the .sh file that is actually modified.

Oops, I'll back it out. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4071

From weijun at openjdk.java.net  Fri May 21 20:01:15 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 20:01:15 GMT
Subject:  RFR: 8267184: Add -Djava.security.manager=allow to
 tests calling System.setSecurityManager [v3]
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: 

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  feedback from Phil
  
  reverted:

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4071/files
  - new: https://git.openjdk.java.net/jdk/pull/4071/files/bfa955ad..9a3ec578

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4071.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4071/head:pull/4071

PR: https://git.openjdk.java.net/jdk/pull/4071

From prr at openjdk.java.net  Fri May 21 20:14:19 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 21 May 2021 20:14:19 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v11]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 20 May 2021 22:25:05 GMT, Alexander Zuev  wrote:

>> Fix updated after first round of review.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Specification of getSystemIcon reworded to get rid of the non-public
>   class reference and to better describe some cornor cases

Please note that I added a number of comments in the CSR itself. 
I had suggestions about what to do in many of the cases but there's a couple of cases where
I could not either divine what was intended or know the best way to phrase it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From weijun at openjdk.java.net  Fri May 21 20:18:58 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 20:18:58 GMT
Subject:  RFR: 8267521: Post JEP 411 refactoring: maximum
 covering > 50K [v2]
In-Reply-To: 
References: 
 
 
Message-ID: <-G6LsP9NmgT4W265oaeXphH-xSg2U-9ofbhBlay7_-w=.0241068a-301f-4f94-802e-69a8adb545a4@github.com>

On Fri, 21 May 2021 15:35:05 GMT, Daniel Fuchs  wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   typo on windows
>
> src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java line 120:
> 
>> 118:                         vals[1] = Integer.getInteger("sun.net.client.defaultConnectTimeout", 300_000).intValue();
>> 119:                         return System.getProperty("file.encoding", "ISO8859_1");
>> 120:                     }
> 
> It is a bit strange that "file.encoding" seem to get a special treatment - but I guess that's OK.

You might say we thus avoid wasting the return value, as much as possible.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4138

From kizune at openjdk.java.net  Fri May 21 20:23:10 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 21 May 2021 20:23:10 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v11]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 21 May 2021 20:10:55 GMT, Phil Race  wrote:

> Please note that I added a number of comments in the CSR itself.
> I had suggestions about what to do in many of the cases but there's a couple of cases where
> I could not either divine what was intended or know the best way to phrase it.

I am responding to CSR comments right now but honestly i would prefer to do a review in one place - preferably here. For some reason i do not receive any notifications from JBS about new comments in CSR so i had to monitor it manually by refreshing the page.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From weijun at openjdk.java.net  Fri May 21 20:23:14 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 20:23:14 GMT
Subject:  RFR: 8267521: Post JEP 411 refactoring: maximum
 covering > 50K [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 21 May 2021 15:37:48 GMT, Daniel Fuchs  wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   typo on windows
>
> src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java line 550:
> 
>> 548:      * @throws IOException if the connection was unsuccessful.
>> 549:      */
>> 550:     @SuppressWarnings("removal")
> 
> Could the scope of the annotation be further reduced by applying it to the two places where `doPrivileged` is called in this method?

I'll probably need to assign the doPriv result on L631 to a tmp variable and then assign it to `s`. Are you OK with this ugliness? Update: Ah, I see you already have similar suggestion in the next comment.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4138

From weijun at openjdk.java.net  Fri May 21 20:37:30 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 20:37:30 GMT
Subject:  RFR: 8267521: Post JEP 411 refactoring: maximum
 covering > 50K [v3]
In-Reply-To: 
References: 
Message-ID: 

> The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed.
> 
> The code change shows some common solutions to avoid such too wide annotations:
> 
> 1. Extract calls into a method and add annotation on that method
> 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value.
> 3. Put declaration and assignment into a single statement if possible.
> 4. Rewrite code to achieve #3 above.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  update FtpClient.java

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4138/files
  - new: https://git.openjdk.java.net/jdk/pull/4138/files/d460efb8..60d97a4c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4138&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4138&range=01-02

  Stats: 23 lines in 1 file changed: 0 ins; 12 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4138.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4138/head:pull/4138

PR: https://git.openjdk.java.net/jdk/pull/4138

From prr at openjdk.java.net  Fri May 21 20:46:03 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 21 May 2021 20:46:03 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
Message-ID: 

On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang  wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

I haven't seen any response to this comment I made a couple of days ago and I suspect it got missed
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

test/jdk/java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java line 59:

> 57:                 ProcessCommunicator
> 58:                         .executeChildProcess(Consumer.class, new String[0]);
> 59:         if (!"Hello".equals(processResults.getStdOut())) {

Who or what prompted this change ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Fri May 21 20:55:02 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 20:55:02 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
Message-ID: 

On Fri, 21 May 2021 20:43:05 GMT, Phil Race  wrote:

> I haven't seen any response to this comment I made a couple of days ago and I suspect it got missed
> 
> > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> > fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
> 
> test/jdk/java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java line 59:
> 
> > 57:                 ProcessCommunicator
> > 58:                         .executeChildProcess(Consumer.class, new String[0]);
> > 59:         if (!"Hello".equals(processResults.getStdOut())) {
> 
> Who or what prompted this change ?

I replied right in the thread but unfortunately GitHub does not display it at the end of page.

This is because the process is now launched with `-Djava.security.manager=allow` (because of another change in https://github.com/openjdk/jdk/pull/4071), and a new warning is displayed in stderr. Therefore I switched to stdout.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From prr at openjdk.java.net  Fri May 21 21:27:07 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 21 May 2021 21:27:07 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v11]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 20 May 2021 22:25:05 GMT, Alexander Zuev  wrote:

>> Fix updated after first round of review.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Specification of getSystemIcon reworded to get rid of the non-public
>   class reference and to better describe some cornor cases

I was reviewing the CSR so comments in the CSR are the obvious place for that.
We can continue it here if you like
1) Will you be updating to explain how we map to (theoretical) non-square icons ?
> As for the square icons - yes, we imply that the greater dimension is specified so in case of 256x128 icon 
> the 256x256 icon will be returned with the 256x128 bitmap inside and the 256x256 reported size.

FWIW I think now I understand that you mean we will always return a square icon, that may be an issue.
Imagine if the OS has icons that are 256x128 or 128x256 and we need to display a bunch of them side by side 
and tow by row you will find it impossible to layout well. Surely we should return the same if we can
It is *theoretically* possible that the platform will do something bananas like return 128x256 then 256x256 then
384x256 alternative images in which case we'd need logic to handle that as sensibly as possible, acc.
to the way MRI handles cuch cases, but if the aspect ratio is consistent as I expect is typical we should support that

2) I can't agree that IAE is wrong for a negative size. The argument that a developer may make a mistake
is not sufficient. Virtually every Image related API we have throws an exception (usually IAE) if you pass <= 0
and folks get that right all the time. Allowing it here would be anomalous.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From kizune at openjdk.java.net  Fri May 21 21:41:44 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 21 May 2021 21:41:44 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v12]
In-Reply-To: 
References: 
Message-ID: 

> Fix updated after first round of review.

Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:

  Chenged implementation specification based on CSR review

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2875/files
  - new: https://git.openjdk.java.net/jdk/pull/2875/files/548dcef1..56285783

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2875&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2875&range=10-11

  Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2875.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2875/head:pull/2875

PR: https://git.openjdk.java.net/jdk/pull/2875

From kizune at openjdk.java.net  Sat May 22 00:59:17 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Sat, 22 May 2021 00:59:17 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v11]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 21 May 2021 21:24:10 GMT, Phil Race  wrote:

> if the aspect ratio is consistent as I expect is typical we should support that

Ok, i see your point. I can do that for sure, it is just a change of API for now, no implementation will be affected since Windows does not support non-square icons for files and passage about exact size can not be guaranteed will save us from "i requested 128x20 and you returned 128x128" complaints. One will get what platform is able to serve. However, i do not see why we should limit the maximum requested size.

> I can't agree that IAE is wrong for a negative size.

How about non-existing file or file? Also IAE?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From serb at openjdk.java.net  Sat May 22 04:07:04 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 22 May 2021 04:07:04 GMT
Subject:  RFR: 8264218: Public method
 javax.swing.JMenu.setComponentOrientation() has no spec [v5]
In-Reply-To: <22JyhhEtdDzZ3uaobbNwCbA7rrcNYYX2Mb6G_zYBkqM=.451f59da-c2b8-4020-b4a6-ed00605305ce@github.com>
References: 
 <22JyhhEtdDzZ3uaobbNwCbA7rrcNYYX2Mb6G_zYBkqM=.451f59da-c2b8-4020-b4a6-ed00605305ce@github.com>
Message-ID: 

On Thu, 1 Apr 2021 16:19:48 GMT, Prasanta Sadhukhan  wrote:

>> A public overriding method JMenu.setComponentOrientation(java.awt.ComponentOrientation)
>> has no spec.
>> Added spec for the method.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   javadoc change

That should not be integrated, if that other bug was closed as not a defect then we assume that in such cases the spec should be hidden if it is the same as in the parent. the spec change w/o CSR? I suggest just rollback it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3213

From alanb at openjdk.java.net  Sat May 22 07:00:03 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 22 May 2021 07:00:03 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 
 
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 
 
 
 <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com>
 
 
 
Message-ID: 

On Fri, 21 May 2021 18:00:13 GMT, Phil Race  wrote:

> Are you suggesting that the patch doesn't need testing as it is ? It should be the same either way.
> It is very straight forward to run the automated tests across all platforms these days.
> I get the impression that no one is guaranteeing to do this straight after integration.
> It sounds like it is up for deferral if time runs out.
> 
> The amount of follow-on work that I am hearing about here, and may be for tests, does not make it sound
> like this JEP is nearly as done as first presented.
> 
> If there was some expectation that groups responsible for an area would get involved with this
> issue which I am assured was already known about, then why was it not raised before and made
> part of the plan ?

Sprinkling SuppressWarnings should be very low risk. Refactoring code to have the scope of the SW be as small as possible may be a bit more risky, esp. in areas where one doesn't know the code or the tests that exercise it. The tests may be good but it's not clear to me that we want to force Max to do significant refactoring in this PR.  PR 4138 has been created as the follow-on PR so I think we should help get that reviewed so that it can be integrated soon after this PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From prr at openjdk.java.net  Sat May 22 16:03:06 2021
From: prr at openjdk.java.net (Phil Race)
Date: Sat, 22 May 2021 16:03:06 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v12]
In-Reply-To: 
References: 
 
Message-ID: <37zATkBtqRk8MwB4mHxnkuMKCSkDVX18ktvFE_5XHOQ=.41372844-b68a-4bf4-8fa6-40826397399d@github.com>

On Fri, 21 May 2021 21:41:44 GMT, Alexander Zuev  wrote:

>> Fix updated after first round of review.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Chenged implementation specification based on CSR review

> > if the aspect ratio is consistent as I expect is typical we should support that
> 
> Ok, i see your point. I can do that for sure, it is just a change of API for now, no implementation will be affected since Windows does not support non-square icons for files and passage about exact size can not be guaranteed will save us from "i requested 128x20 and you returned 128x128" complaints. One will get what platform is able to serve. However, i do not see why we should limit the maximum requested size.

Did I say that?  I think I said something more like the opposite.

The spec you wrote seems to suggest that if the user exceeds some unknown size that you aren't telling them,
you'll return null, leaving them in a guessing game as to what is the maximum.
That can't be right.
So either you provide another API telling them the maximum size, or, if they exceed the maximum size
you specify that the API will return the best fit, just like in other cases.

The question I raised was around what "size" means. If you meant the API to return the size to
which the image will *scale* when drawn, you need to make this very clear to the developer,
or since you don't have an API telling them the max available, they'll respond by asking for ridiculous sizes
to get the best quality image. 

So what do you intend ?



> 
> > I can't agree that IAE is wrong for a negative size.
> 
> How about non-existing file or file? Also IAE?

First .. "inaccessible" should not be distinguishable from "non-existing".
If I ask for a file that the system has hidden from me for whatever reason.
Now since this is something where the app may not know that for platform reasons,
I think a file that cannot be "found" should not throw IAE, just return null.

Passing in null directly tho' probably *should* be IAE because what are they doing that for ??

src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 280:

> 278:     * @param size width and height of the icon in user coordinate system.
> 279:     * This API only supports square icons with the edge length
> 280:     * equals or greater than 1. Maximum size allowed is defined by the

I think this is a weird way to say size >=1.

We should throw IAE for <=0 .

I also think we need to allow for rectangular icons,  not bake it in to the spec in such strong terms that we don't.
I suppose  it could be revised if a platform that needs it comes along but  ...

Still not sure about failing if you exceed the maximum size.

Why ? Why not just return the largest possible - it is the same thing as other cases, we'll return the best match.

If that is what you already mean, then say it more clearly.

src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 284:

> 282:     * @return an icon as it would be displayed by a native file chooser
> 283:     * or null if invalid parameters are passed such as pointer to a
> 284:     * non-existing file or a size outside of supported range.

pointer -> reference

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From mullan at openjdk.java.net  Sun May 23 16:40:59 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Sun, 23 May 2021 16:40:59 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
Message-ID: 

On Fri, 21 May 2021 15:27:39 GMT, Daniel Fuchs  wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
>
> src/java.base/share/classes/java/lang/SecurityManager.java line 104:
> 
>> 102:  * method will throw an {@code UnsupportedOperationException}). If the
>> 103:  * {@systemProperty java.security.manager} system property is set to the
>> 104:  * special token "{@code allow}", then a security manager will not be set at
> 
> Can/should the `{@systemProperty ...}` tag be used more than once for a given system property? I thought it should be used only once, at the place where the system property is defined. Maybe @jonathan-gibbons can offer some more guidance on this.

Good point. I would remove the extra @systemProperty tags on lines 103, 106, and 113. Also, in `System.setSecurityManager` there are 3 @systemProperty java.security.manager tags, I would just keep the first one. (I think it's ok to have more than one, if they are defined in different APIs).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From dfuchs at openjdk.java.net  Mon May 24 09:03:10 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 24 May 2021 09:03:10 GMT
Subject:  RFR: 8267521: Post JEP 411 refactoring: maximum
 covering > 50K [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 21 May 2021 20:37:30 GMT, Weijun Wang  wrote:

>> The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed.
>> 
>> The code change shows some common solutions to avoid such too wide annotations:
>> 
>> 1. Extract calls into a method and add annotation on that method
>> 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value.
>> 3. Put declaration and assignment into a single statement if possible.
>> 4. Rewrite code to achieve #3 above.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update FtpClient.java

Thanks for taking in my suggestions for FtpClient. I have also reviewed the changes to java.util.logging and JMX. I wish there was a way to handle doPrivileged returning void more nicely. Maybe component maintainers will be able to deal with them on a case-by-case basis later on.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4138

From weijun at openjdk.java.net  Mon May 24 13:53:34 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 24 May 2021 13:53:34 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v4]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: 

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
> 
> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  keep only one systemProperty tag

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4073/files
  - new: https://git.openjdk.java.net/jdk/pull/4073/files/c4221b5f..1f6ff6c4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=02-03

  Stats: 8 lines in 2 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Mon May 24 13:53:37 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 24 May 2021 13:53:37 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v4]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
Message-ID: 

On Sun, 23 May 2021 16:35:43 GMT, Sean Mullan  wrote:

>> src/java.base/share/classes/java/lang/SecurityManager.java line 104:
>> 
>>> 102:  * method will throw an {@code UnsupportedOperationException}). If the
>>> 103:  * {@systemProperty java.security.manager} system property is set to the
>>> 104:  * special token "{@code allow}", then a security manager will not be set at
>> 
>> Can/should the `{@systemProperty ...}` tag be used more than once for a given system property? I thought it should be used only once, at the place where the system property is defined. Maybe @jonathan-gibbons can offer some more guidance on this.
>
> Good point. I would remove the extra @systemProperty tags on lines 103, 106, and 113. Also, in `System.setSecurityManager` there are 3 @systemProperty java.security.manager tags, so we should remove those too.

New commit pushed. There is only one `@systemProperty` tag now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Mon May 24 14:05:08 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 24 May 2021 14:05:08 GMT
Subject:  RFR: 8267184: Add -Djava.security.manager=allow to
 tests calling System.setSecurityManager [v4]
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: 

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

Weijun Wang 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 20 additional commits since the last revision:

 - Merge branch 'master' into 8267184
 - feedback from Phil
   
   reverted:
 - adjust order of VM options
 - test for awt
 - test for hotspot-gc
 - test for compiler
 - test for net
 - test for core-libs
 - test for beans
 - test for xml
 - ... and 10 more: https://git.openjdk.java.net/jdk/compare/37f74de7...412264a0

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4071/files
  - new: https://git.openjdk.java.net/jdk/pull/4071/files/9a3ec578..412264a0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=02-03

  Stats: 12227 lines in 453 files changed: 6978 ins; 3721 del; 1528 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4071.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4071/head:pull/4071

PR: https://git.openjdk.java.net/jdk/pull/4071

From weijun at openjdk.java.net  Mon May 24 17:02:13 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 24 May 2021 17:02:13 GMT
Subject:  Integrated: 8267184: Add -Djava.security.manager=allow
 to tests calling System.setSecurityManager
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: <3rH0Qzq38uj4gzgkoDyLE_SnE47c8710ZvGAeSK6UA4=.e080d8bc-838b-4d62-87ff-ca8b12445c8a@github.com>

On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang  wrote:

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

This pull request has now been integrated.

Changeset: 640a2afd
Author:    Weijun Wang 
URL:       https://git.openjdk.java.net/jdk/commit/640a2afda36857410b7abf398af81e35430a62e7
Stats:     1028 lines in 852 files changed: 252 ins; 9 del; 767 mod

8267184: Add -Djava.security.manager=allow to tests calling System.setSecurityManager

Co-authored-by: Lance Andersen 
Co-authored-by: Weijun Wang 
Reviewed-by: dholmes, alanb, dfuchs, mchung, mullan, prr

-------------

PR: https://git.openjdk.java.net/jdk/pull/4071

From weijun at openjdk.java.net  Mon May 24 21:51:32 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 24 May 2021 21:51:32 GMT
Subject:  RFR: 8267521: Post JEP 411 refactoring: maximum
 covering > 50K [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 24 May 2021 09:00:07 GMT, Daniel Fuchs  wrote:

> Thanks for taking in my suggestions for FtpClient. I have also reviewed the changes to java.util.logging and JMX. I wish there was a way to handle doPrivileged returning void more nicely. Maybe component maintainers will be able to deal with them on a case-by-case basis later on.

Assigning to a useless "dummy" variable looks ugly. Extracting the call to a method might make it faraway from its caller. In L114 of `FtpClient.java` I managed to invent a return value and I thought it was perfect. But you said it's "a bit strange". :-(

-------------

PR: https://git.openjdk.java.net/jdk/pull/4138

From kizune at openjdk.java.net  Tue May 25 22:01:36 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 25 May 2021 22:01:36 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v13]
In-Reply-To: 
References: 
Message-ID: 

> Fix updated after first round of review.

Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:

  Changed API to support non-square icons and updated documentation
  accordingly
  Fixed test to support updated API
  Added negative test cases

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2875/files
  - new: https://git.openjdk.java.net/jdk/pull/2875/files/56285783..d679dc01

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2875&range=12
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2875&range=11-12

  Stats: 59 lines in 4 files changed: 34 ins; 3 del; 22 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2875.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2875/head:pull/2875

PR: https://git.openjdk.java.net/jdk/pull/2875

From kizune at openjdk.java.net  Tue May 25 22:01:43 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 25 May 2021 22:01:43 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v12]
In-Reply-To: <37zATkBtqRk8MwB4mHxnkuMKCSkDVX18ktvFE_5XHOQ=.41372844-b68a-4bf4-8fa6-40826397399d@github.com>
References: 
 
 <37zATkBtqRk8MwB4mHxnkuMKCSkDVX18ktvFE_5XHOQ=.41372844-b68a-4bf4-8fa6-40826397399d@github.com>
Message-ID: 

On Fri, 21 May 2021 22:07:30 GMT, Phil Race  wrote:

>> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Chenged implementation specification based on CSR review
>
> src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 280:
> 
>> 278:     * @param size width and height of the icon in user coordinate system.
>> 279:     * This API only supports square icons with the edge length
>> 280:     * equals or greater than 1. Maximum size allowed is defined by the
> 
> I think this is a weird way to say size >=1.
> 
> We should throw IAE for <=0 .
> 
> I also think we need to allow for rectangular icons,  not bake it in to the spec in such strong terms that we don't.
> I suppose  it could be revised if a platform that needs it comes along but  ...
> 
> Still not sure about failing if you exceed the maximum size.
> 
> Why ? Why not just return the largest possible - it is the same thing as other cases, we'll return the best match.
> 
> If that is what you already mean, then say it more clearly.

Ok, in order to allow rectangular items API needs to be slightly modified and tests and documentation should be amended accordingly. I did that, please take a look, once it is settled i will update and finalize CSR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From prr at openjdk.java.net  Tue May 25 23:20:28 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 25 May 2021 23:20:28 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v13]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 25 May 2021 22:01:36 GMT, Alexander Zuev  wrote:

>> Fix updated after first round of review.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changed API to support non-square icons and updated documentation
>   accordingly
>   Fixed test to support updated API
>   Added negative test cases

src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 282:

> 280:     * @return an icon as it would be displayed by a native file chooser
> 281:     * or null if invalid parameters are passed such as reference to a
> 282:     * non-existing file.

non-existent not non-existing, but I think null deserves an IAE - as I had written a couple of days ago.

I see you dropped the words about null if the size is too large.
Should I interpret that as meaning one of the things I suggested - that this is just another case of a closest match ?

src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 286:

> 284:     * @see AbstractMultiResolutionImage
> 285:     * @see FileSystemView#getSystemIcon(File)
> 286:     * @since 17

You need to add the IAE to the javadoc.

src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 290:

> 288:     public Icon getSystemIcon(File f, int width, int height) {
> 289:         if (height <1 || width < 1) {
> 290:             throw new IllegalArgumentException("Icon size can not be below 1");

(minor) spacing. <1

src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 294:

> 292: 
> 293:         if (f == null || !f.exists()) {
> 294:             return null;

I suggested the a null File ought to be IAE too - this is showing up in the conversation thread but not here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From kizune at openjdk.java.net  Tue May 25 23:36:45 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 25 May 2021 23:36:45 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v13]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 25 May 2021 23:17:39 GMT, Phil Race  wrote:

>> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changed API to support non-square icons and updated documentation
>>   accordingly
>>   Fixed test to support updated API
>>   Added negative test cases
>
> src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 282:
> 
>> 280:     * @return an icon as it would be displayed by a native file chooser
>> 281:     * or null if invalid parameters are passed such as reference to a
>> 282:     * non-existing file.
> 
> non-existent not non-existing, but I think null deserves an IAE - as I had written a couple of days ago.
> 
> I see you dropped the words about null if the size is too large.
> Should I interpret that as meaning one of the things I suggested - that this is just another case of a closest match ?

Thanks for correction. Yes - we will return the best match no matter how big the requested size is.

Fixed IAE in case of null file.

> src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 286:
> 
>> 284:     * @see AbstractMultiResolutionImage
>> 285:     * @see FileSystemView#getSystemIcon(File)
>> 286:     * @since 17
> 
> You need to add the IAE to the javadoc.

Done.

> src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 290:
> 
>> 288:     public Icon getSystemIcon(File f, int width, int height) {
>> 289:         if (height <1 || width < 1) {
>> 290:             throw new IllegalArgumentException("Icon size can not be below 1");
> 
> (minor) spacing. <1

Typo. Fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From kizune at openjdk.java.net  Tue May 25 23:36:43 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 25 May 2021 23:36:43 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v14]
In-Reply-To: 
References: 
Message-ID: 

> Fix updated after first round of review.

Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:

  null file now properly causes IllegalArgumentException
  Small fixed in JavaDoc

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2875/files
  - new: https://git.openjdk.java.net/jdk/pull/2875/files/d679dc01..b3ca9da6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2875&range=13
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2875&range=12-13

  Stats: 9 lines in 1 file changed: 6 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2875.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2875/head:pull/2875

PR: https://git.openjdk.java.net/jdk/pull/2875

From prr at openjdk.java.net  Wed May 26 14:57:20 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 26 May 2021 14:57:20 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v14]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 25 May 2021 23:36:43 GMT, Alexander Zuev  wrote:

>> Fix updated after first round of review.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   null file now properly causes IllegalArgumentException
>   Small fixed in JavaDoc

Approving but fix  the grammar!

src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 282:

> 280:     * @return an icon as it would be displayed by a native file chooser
> 281:     * or null if invalid parameters are passed such as reference to a
> 282:     * non-existent file.

grammar : "a reference"

src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 285:

> 283:     * @throws IllegalArgumentException if invalid parameter such
> 284:     * as negative size or null file reference is passed.
> 285:     * @see JFileChooser#getIcon

minor grammar : add "an"or "a" as appropriate, ie change to : 
"if an invalid parameter such a negative size or a null file reference"

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2875

From aivanov at openjdk.java.net  Wed May 26 15:26:26 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 26 May 2021 15:26:26 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v14]
In-Reply-To: 
References: 
 
Message-ID: <5a5-vFhzH24FsvivkhWjLIbT9tuE5I-XpShRyXAoRP0=.213cc7ce-f77f-4188-a987-ef83db01901b@github.com>

On Tue, 25 May 2021 23:36:43 GMT, Alexander Zuev  wrote:

>> Fix updated after first round of review.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   null file now properly causes IllegalArgumentException
>   Small fixed in JavaDoc

src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 296:

> 294: 
> 295:         if (f == null){
> 296:             throw new IllegalArgumentException("File reference should be specified");

Shall the exception message be more specific: "The file reference should not be null"?

src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 300:

> 298: 
> 299:         if(!f.exists()) {
> 300:             return null;

Shall it throw `FileNotFoundException` or `IllegalArgumentException` if the file doesn't exist?
It could more convenient to return `null` rather than catch an exception.

The space is missing between if and the opening parenthesis.

test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java line 58:

> 56: 
> 57:     static void negativeTests() {
> 58:         ImageIcon icon;

Can it be icon? This test doesn't use the fact that the returned object is `ImageIcon`.

test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java line 67:

> 65:         if (!gotException) {
> 66:             throw new RuntimeException("Negative size icon should throw invalid argument exception");
> 67:         }

A suggestion: throw the exception inside try-block and ignore the expected exception, then `gotException` can be dropped.
Suggestion:

        try {
            fsv.getSystemIcon(new File("."), -1, 16);
            throw new RuntimeException("Negative size icon should throw invalid argument exception");
        } catch (IllegalArgumentException iae) {
            // expected
        }


Shall the test also exercise 0 as an invalid parameter? Shall the test also pass an invalid height?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From kizune at openjdk.java.net  Wed May 26 16:06:22 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 26 May 2021 16:06:22 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v14]
In-Reply-To: 
References: 
 
 <5a5-vFhzH24FsvivkhWjLIbT9tuE5I-XpShRyXAoRP0=.213cc7ce-f77f-4188-a987-ef83db01901b@github.com>
 
Message-ID: 

On Wed, 26 May 2021 16:03:02 GMT, Alexander Zuev  wrote:

>> test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java line 67:
>> 
>>> 65:         if (!gotException) {
>>> 66:             throw new RuntimeException("Negative size icon should throw invalid argument exception");
>>> 67:         }
>> 
>> A suggestion: throw the exception inside try-block and ignore the expected exception, then `gotException` can be dropped.
>> Suggestion:
>> 
>>         try {
>>             fsv.getSystemIcon(new File("."), -1, 16);
>>             throw new RuntimeException("Negative size icon should throw invalid argument exception");
>>         } catch (IllegalArgumentException iae) {
>>             // expected
>>         }
>> 
>> 
>> Shall the test also exercise 0 as an invalid parameter? Shall the test also pass an invalid height?
>
> Fixed.

I do not think such detailed testing is required. After all it is not a full spec conformance test.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From kizune at openjdk.java.net  Wed May 26 16:06:22 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 26 May 2021 16:06:22 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v14]
In-Reply-To: <5a5-vFhzH24FsvivkhWjLIbT9tuE5I-XpShRyXAoRP0=.213cc7ce-f77f-4188-a987-ef83db01901b@github.com>
References: 
 
 <5a5-vFhzH24FsvivkhWjLIbT9tuE5I-XpShRyXAoRP0=.213cc7ce-f77f-4188-a987-ef83db01901b@github.com>
Message-ID: 

On Wed, 26 May 2021 15:07:30 GMT, Alexey Ivanov  wrote:

>> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   null file now properly causes IllegalArgumentException
>>   Small fixed in JavaDoc
>
> src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 296:
> 
>> 294: 
>> 295:         if (f == null){
>> 296:             throw new IllegalArgumentException("File reference should be specified");
> 
> Shall the exception message be more specific: "The file reference should not be null"?

Ficed.

> test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java line 58:
> 
>> 56: 
>> 57:     static void negativeTests() {
>> 58:         ImageIcon icon;
> 
> Can it be icon? This test doesn't use the fact that the returned object is `ImageIcon`.

Fixed.

> test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java line 67:
> 
>> 65:         if (!gotException) {
>> 66:             throw new RuntimeException("Negative size icon should throw invalid argument exception");
>> 67:         }
> 
> A suggestion: throw the exception inside try-block and ignore the expected exception, then `gotException` can be dropped.
> Suggestion:
> 
>         try {
>             fsv.getSystemIcon(new File("."), -1, 16);
>             throw new RuntimeException("Negative size icon should throw invalid argument exception");
>         } catch (IllegalArgumentException iae) {
>             // expected
>         }
> 
> 
> Shall the test also exercise 0 as an invalid parameter? Shall the test also pass an invalid height?

Fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From kizune at openjdk.java.net  Wed May 26 16:52:38 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 26 May 2021 16:52:38 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v15]
In-Reply-To: 
References: 
Message-ID: 

> Fix updated after first round of review.

Alexander Zuev has updated the pull request incrementally with two additional commits since the last revision:

 - Fixed small errors
   Adjustments in the test
 - Grammar fix in method documentation

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2875/files
  - new: https://git.openjdk.java.net/jdk/pull/2875/files/b3ca9da6..9e7bf901

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2875&range=14
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2875&range=13-14

  Stats: 17 lines in 2 files changed: 3 ins; 6 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2875.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2875/head:pull/2875

PR: https://git.openjdk.java.net/jdk/pull/2875

From aivanov at openjdk.java.net  Wed May 26 17:01:21 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 26 May 2021 17:01:21 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v15]
In-Reply-To: 
References: 
 
Message-ID: <33EM8M3IOlQk-X1o5tPm7gvGnTlFD0jhgGrVP34Bfrg=.04efec4a-7643-4e1b-ae04-57693fbad2cc@github.com>

On Wed, 26 May 2021 16:52:38 GMT, Alexander Zuev  wrote:

>> Fix updated after first round of review.
>
> Alexander Zuev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fixed small errors
>    Adjustments in the test
>  - Grammar fix in method documentation

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From prr at openjdk.java.net  Wed May 26 17:43:22 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 26 May 2021 17:43:22 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v14]
In-Reply-To: <5a5-vFhzH24FsvivkhWjLIbT9tuE5I-XpShRyXAoRP0=.213cc7ce-f77f-4188-a987-ef83db01901b@github.com>
References: 
 
 <5a5-vFhzH24FsvivkhWjLIbT9tuE5I-XpShRyXAoRP0=.213cc7ce-f77f-4188-a987-ef83db01901b@github.com>
Message-ID: 

On Wed, 26 May 2021 15:15:42 GMT, Alexey Ivanov  wrote:

>> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   null file now properly causes IllegalArgumentException
>>   Small fixed in JavaDoc
>
> src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 300:
> 
>> 298: 
>> 299:         if(!f.exists()) {
>> 300:             return null;
> 
> Shall it throw `FileNotFoundException` or `IllegalArgumentException` if the file doesn't exist?
> It could more convenient to return `null` rather than catch an exception.
> 
> The space is missing between if and the opening parenthesis.

It definitely should not be IAE. But FNFE is a reasonable idea.
However it changes the usage since it is a checked exception.
I'm on the fence and could go either way.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From aivanov at openjdk.java.net  Wed May 26 19:45:13 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 26 May 2021 19:45:13 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v14]
In-Reply-To: 
References: 
 
 <5a5-vFhzH24FsvivkhWjLIbT9tuE5I-XpShRyXAoRP0=.213cc7ce-f77f-4188-a987-ef83db01901b@github.com>
 
Message-ID: 

On Wed, 26 May 2021 17:40:44 GMT, Phil Race  wrote:

>> src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 300:
>> 
>>> 298: 
>>> 299:         if(!f.exists()) {
>>> 300:             return null;
>> 
>> Shall it throw `FileNotFoundException` or `IllegalArgumentException` if the file doesn't exist?
>> It could more convenient to return `null` rather than catch an exception.
>> 
>> The space is missing between if and the opening parenthesis.
>
> It definitely should not be IAE. But FNFE is a reasonable idea.
> However it changes the usage since it is a checked exception.
> I'm on the fence and could go either way.

The older similar method, `getSystemIcon(File f)`, returns `null` if the file doesn't exist. It could make sense to preserve the behaviour from this point of view and not to make the user of the API handle FNFE; thus the new method could easily be used instead.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From serb at openjdk.java.net  Wed May 26 21:10:25 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 26 May 2021 21:10:25 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v15]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 26 May 2021 16:52:38 GMT, Alexander Zuev  wrote:

>> Fix updated after first round of review.
>
> Alexander Zuev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fixed small errors
>    Adjustments in the test
>  - Grammar fix in method documentation

Did somebody run the test on Linux and macOS, Does our stub implementation there confirms the specification?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From serb at openjdk.java.net  Wed May 26 21:42:16 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 26 May 2021 21:42:16 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v7]
In-Reply-To: 
References: 
 
 
 
 
 <1WLwml_6PHy_gkPSSz18FpM8AEiFCVDGfR1S06ZxBGk=.b245e8e7-686c-4018-853b-984a35c1fecd@github.com>
 
 
 
 
 
 <1sysgP9ZDpZR3PBvXHWLCo8FU87rEFSvya58vutrmcQ=.22f273a3-d740-4e7c-ad37-e9c128fdb5df@github.com>
 <5JM-jypDvy8tIap4gepmRg5kRJkRj7qfPkFl3ATCMps=.491aa8f2-0ee3-4541-a10b-5b9b26c0bcf2@github.com>
 
 <23JNwdRJ_IfCF2uO6fwuvlCBvYzcymPQwgylxg2KZDA=.b37c4b73-415d-4b31-876f-98dbfac7e89c@github.com>
 
 
 
Message-ID: <7fHkqRDDYA0qYlb_NZzv0pldVAa5fgykdLvz5Rfc37U=.cb28fbf6-bbfa-4c14-84a6-2d653886fdc1@github.com>

On Fri, 21 May 2021 19:37:19 GMT, Alexander Zuev  wrote:

>> Didn't you answer your question already? If `FileSystemView.getRoots()` returns Desktop in Windows shell namespace. Otherwise, I don't know a way to get a reference to a *virtual* folder in Windows shell namespace which doesn't reference a file system object.
>> 
>> Alex's example uses "3D Objects" folder which is one of the known folders and has its own icon instead of the standard folder icon.
>> 
>> It's possible that I don't understand the question clearly.
>> 
>> Alex's fix affects WindowsPlacesBar on the left of JFileChooser in Windows LaF, the icons there look crispier in High DPI environment.
>
>> But how you got them via this method? I am not sure what parameters should be passed to it.
> `
> String userdir = System.getenv("userprofile");
> Icon icon = FileSystemView.getFileSystemView().getSystemIcon(new File(userdir + "\\3D Objects"), 64);
> `
> 
> For some of the libraries getting file reference is quite easy, for some - not so much. But still doable.

Great!

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From serb at openjdk.java.net  Wed May 26 21:42:18 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 26 May 2021 21:42:18 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v15]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 26 May 2021 16:52:38 GMT, Alexander Zuev  wrote:

>> Fix updated after first round of review.
>
> Alexander Zuev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fixed small errors
>    Adjustments in the test
>  - Grammar fix in method documentation

test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java line 77:

> 75:         int[] sizes = new int[] {16, 32, 48, 64, 128};
> 76:         for (int size : sizes) {
> 77:             ImageIcon icon = (ImageIcon) fsv.getSystemIcon(file, size, size);

Is this cast allowed without instanceof check?

test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java line 87:

> 85:             }
> 86: 
> 87:             if (implComplete && icon.getIconWidth() != size) {

Why the size of the returned images might be different? The spec state the size parameter in the getSystemIcon is the size of the icon in the userspace.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From kizune at openjdk.java.net  Wed May 26 21:42:19 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 26 May 2021 21:42:19 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v15]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 26 May 2021 21:12:16 GMT, Sergey Bylokhov  wrote:

>> Alexander Zuev has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fixed small errors
>>    Adjustments in the test
>>  - Grammar fix in method documentation
>
> test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java line 77:
> 
>> 75:         int[] sizes = new int[] {16, 32, 48, 64, 128};
>> 76:         for (int size : sizes) {
>> 77:             ImageIcon icon = (ImageIcon) fsv.getSystemIcon(file, size, size);
> 
> Is this cast allowed without instanceof check?

On Windows - yes. When implementation is complete on other platforms test will have to be updated depending on the way it will be implemented there.

> test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java line 87:
> 
>> 85:             }
>> 86: 
>> 87:             if (implComplete && icon.getIconWidth() != size) {
> 
> Why the size of the returned images might be different? The spec state the size parameter in the getSystemIcon is the size of the icon in the userspace.

The spec says that we are taking into consideration requested sizes but depending on the platform implementation exact match can not be guaranteed. On Windows it can so i'm checking for that.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From prr at openjdk.java.net  Thu May 27 00:22:14 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 27 May 2021 00:22:14 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v15]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Wed, 26 May 2021 21:37:44 GMT, Alexander Zuev  wrote:

>> test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java line 77:
>> 
>>> 75:         int[] sizes = new int[] {16, 32, 48, 64, 128};
>>> 76:         for (int size : sizes) {
>>> 77:             ImageIcon icon = (ImageIcon) fsv.getSystemIcon(file, size, size);
>> 
>> Is this cast allowed without instanceof check?
>
> On Windows - yes. When implementation is complete on other platforms test will have to be updated depending on the way it will be implemented there.

Hmm .. I focused too much on the spec it seems. The API returns Icon and the test should not
"know" or depend on it being anything more specific.
Why does it need to do this ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From prr at openjdk.java.net  Thu May 27 00:22:13 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 27 May 2021 00:22:13 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v15]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 26 May 2021 16:52:38 GMT, Alexander Zuev  wrote:

>> Fix updated after first round of review.
>
> Alexander Zuev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fixed small errors
>    Adjustments in the test
>  - Grammar fix in method documentation

test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java line 28:

> 26:  * @bug 8182043
> 27:  * @summary Access to Windows Large Icons
> 28:  * sun.awt.shell.ShellFolder

What's the comment here mean ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From kizune at openjdk.java.net  Thu May 27 01:37:14 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 27 May 2021 01:37:14 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v15]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 27 May 2021 00:18:13 GMT, Phil Race  wrote:

>> Alexander Zuev has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fixed small errors
>>    Adjustments in the test
>>  - Grammar fix in method documentation
>
> test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java line 28:
> 
>> 26:  * @bug 8182043
>> 27:  * @summary Access to Windows Large Icons
>> 28:  * sun.awt.shell.ShellFolder
> 
> What's the comment here mean ?

That's a leftover from the first iteration of the test. I guess i have to remove it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From kizune at openjdk.java.net  Thu May 27 01:42:17 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 27 May 2021 01:42:17 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v15]
In-Reply-To: 
References: 
 
Message-ID: <-bS7L-fRMEgA1Ottnfqf90eXsbJdNRCsxpRQJlVVgBM=.860e27ec-2481-4a12-b91d-ca22ec923443@github.com>

On Wed, 26 May 2021 16:52:38 GMT, Alexander Zuev  wrote:

>> Fix updated after first round of review.
>
> Alexander Zuev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fixed small errors
>    Adjustments in the test
>  - Grammar fix in method documentation

> Why does it need to do this ?

I'm testing the implementation here and i know that on Windows for these well known files and folders it is possible to get icons of all the sizes mentioned in the test and we will return the correct icon size - so that's what i'm testing it this way.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From kizune at openjdk.java.net  Thu May 27 02:03:15 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 27 May 2021 02:03:15 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v15]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 26 May 2021 21:06:49 GMT, Sergey Bylokhov  wrote:

> Did somebody run the test on Linux and macOS, Does our stub implementation there confirms the specification?

I did run fill tier4 and visually compared the JFileChooser appearance on both Linux and Mac OS X - this change introduced no visual degradation to them and the test passed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From kizune at openjdk.java.net  Thu May 27 02:22:35 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 27 May 2021 02:22:35 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v16]
In-Reply-To: 
References: 
Message-ID: 

> Fix updated after first round of review.

Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:

  Test comment fixed.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2875/files
  - new: https://git.openjdk.java.net/jdk/pull/2875/files/9e7bf901..06521978

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2875&range=15
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2875&range=14-15

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2875.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2875/head:pull/2875

PR: https://git.openjdk.java.net/jdk/pull/2875

From github.com+79671271+rajamah at openjdk.java.net  Thu May 27 09:55:16 2021
From: github.com+79671271+rajamah at openjdk.java.net (rajat mahajan)
Date: Thu, 27 May 2021 09:55:16 GMT
Subject:  RFR: 8266902: Remove final modifier from static methods
 in swing.text.Utilities
Message-ID: 

Summary: Removed redundant usage of final modifier from static methods in javax.swing.Utilities, since static methods are not inherited and cannot be overridden.

-------------

Commit messages:
 - 8266902: Remove final modifier from static methods in swing.text.Utilities

Changes: https://git.openjdk.java.net/jdk/pull/4171/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4171&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266902
  Stats: 17 lines in 1 file changed: 0 ins; 0 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4171.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4171/head:pull/4171

PR: https://git.openjdk.java.net/jdk/pull/4171

From serb at openjdk.java.net  Thu May 27 16:19:16 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 27 May 2021 16:19:16 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v15]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Wed, 26 May 2021 21:39:19 GMT, Alexander Zuev  wrote:

>> test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java line 87:
>> 
>>> 85:             }
>>> 86: 
>>> 87:             if (implComplete && icon.getIconWidth() != size) {
>> 
>> Why the size of the returned images might be different? The spec state the size parameter in the getSystemIcon is the size of the icon in the userspace.
>
> The spec says that we are taking into consideration requested sizes but depending on the platform implementation exact match can not be guaranteed. On Windows it can so i'm checking for that.

Is this requirement is so important? can we return an MRI(same as on Windows) which will have just one resolution? Otherwise what the user should do if the requested size was 32x32 but returned image will be 21x21? Paint the small icon or rescale it by the application?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From kizune at openjdk.java.net  Thu May 27 16:41:12 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 27 May 2021 16:41:12 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v15]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Thu, 27 May 2021 16:16:19 GMT, Sergey Bylokhov  wrote:

> Is this requirement is so important? can we return an MRI(same as on Windows) which will have just one resolution?

We might - when the implementation will be done on other platforms. Probably it will be done by me, probably - by someone else. Right now we return whatever we have so on Linux it is UIManager default icons for file or a folder (which is exactly what any file manager on Linux shows for any file and this is exactly what we promised in the method description). In the future it can change but for now it is all we can guarantee.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From prr at openjdk.java.net  Thu May 27 17:15:06 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 27 May 2021 17:15:06 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v4]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
Message-ID: 

On Mon, 24 May 2021 13:53:34 GMT, Weijun Wang  wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   keep only one systemProperty tag

Marked as reviewed by prr (Reviewer).

I'm OK with this now given that the refactoring is already underway at https://github.com/openjdk/jdk/pull/4138

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From prr at openjdk.java.net  Thu May 27 17:46:07 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 27 May 2021 17:46:07 GMT
Subject:  RFR: 8267521: Post JEP 411 refactoring: maximum
 covering > 50K [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 21 May 2021 20:37:30 GMT, Weijun Wang  wrote:

>> The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed.
>> 
>> The code change shows some common solutions to avoid such too wide annotations:
>> 
>> 1. Extract calls into a method and add annotation on that method
>> 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value if not void. The local variable will be called `tmp` if later reassigned or `dummy` if it will be discarded.
>> 3. Put declaration and assignment into a single statement if possible.
>> 4. Rewrite code to achieve #3 above.
>> 
>> I'll add a copyright year update commit before integration.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update FtpClient.java

src/java.desktop/share/classes/java/awt/Component.java line 630:

> 628:         }
> 629: 
> 630:         @SuppressWarnings("removal")

I'm confused. I thought the reason this wasn't done in the JEP implementation PR is because of refactoring
that was needed because of the usage in this static block and you could not apply the annotation here.
Yet it seems you are doing exactly what was supposed to be impossible with no refactoring.
Can you explain ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4138

From weijun at openjdk.java.net  Thu May 27 20:16:25 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 27 May 2021 20:16:25 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v5]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: 

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
> 
> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.

Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - move one annotation to new method
 - merge from master, two files removed, one needs merge
 - keep only one systemProperty tag
 - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
 - feedback from Sean, Phil and Alan
 - add supresswarnings annotations automatically
 - manual change before automatic annotating
 - 8266459: Implement JEP 411: Deprecate the Security Manager for Removal

-------------

Changes: https://git.openjdk.java.net/jdk/pull/4073/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=04
  Stats: 2022 lines in 825 files changed: 1884 ins; 10 del; 128 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

PR: https://git.openjdk.java.net/jdk/pull/4073

From kizune at openjdk.java.net  Thu May 27 21:52:22 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 27 May 2021 21:52:22 GMT
Subject:  Integrated: 8182043: Access to Windows Large Icons
In-Reply-To: 
References: 
Message-ID: 

On Mon, 8 Mar 2021 13:22:07 GMT, Alexander Zuev  wrote:

> Fix updated after first round of review.

This pull request has now been integrated.

Changeset: 7f52c50b
Author:    Alexander Zuev 
URL:       https://git.openjdk.java.net/jdk/commit/7f52c50ba32eecf5f379f8db30ac6a5cc50b3b66
Stats:     408 lines in 6 files changed: 328 ins; 39 del; 41 mod

8182043: Access to Windows Large Icons

Reviewed-by: aivanov, azvegint, prr

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From serb at openjdk.java.net  Fri May 28 00:50:17 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 28 May 2021 00:50:17 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v15]
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: <5bZ3TtS--Yfafva0uwasgiaZyNqWaRDT-QpnKeQxfH4=.a7e26572-8ab9-4a31-b9aa-ee8d5a722585@github.com>

On Thu, 27 May 2021 16:38:02 GMT, Alexander Zuev  wrote:

>> Is this requirement is so important? can we return an MRI(same as on Windows) which will have just one resolution? Otherwise what the user should do if the requested size was 32x32 but returned image will be 21x21? Paint the small icon or rescale it by the application?
>
>> Is this requirement is so important? can we return an MRI(same as on Windows) which will have just one resolution?
> 
> We might - when the implementation will be done on other platforms. Probably it will be done by me, probably - by someone else. Right now we return whatever we have so on Linux it is UIManager default icons for file or a folder (which is exactly what any file manager on Linux shows for any file and this is exactly what we promised in the method description). In the future it can change but for now it is all we can guarantee.

This is my point I think we should update this implementation to always return MRI of the requested size, otherwise, the code example of this will look like this:

    Icon icon = fsv.getSystemIcon(file, width, height);
    if (icon.getIconWidth() != width && icon.getIconHeight() != height) {
        return scaleTheIconInTheSameWayAsBeforeTheFix(icon, width, height);
    } else if (icon instanceof ImageIcon) {
        ImageIcon imageIcon = (ImageIcon) icon;
        if (icon.getImage() instanceof MultiResolutionImage) {
            MultiResolutionImage mri = (MultiResolutionImage) icon.getImage();
            return  mri.getResolutionVariant(width, height);
        } else {
            return imageIcon;
        }
    } else {
        return icon;
    }

I pretty sure we can do better than the code above.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From serb at openjdk.java.net  Fri May 28 01:06:20 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 28 May 2021 01:06:20 GMT
Subject:  RFR: 8182043: Access to Windows Large Icons [v16]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Fri, 7 May 2021 17:53:49 GMT, Alexander Zuev  wrote:

>> This comment is also about the case of not fetching icons of sizes smaller than requested size.
>
> Sorry, missed that in my latest fix. Indeed there is no legitimate ways to set scaling factor to less than 100% on Windows so yes, omitting the icons that are less than expected size. As for starting the count from the correct index - to get the correct index we would have to traverse the array of possible resolutions anyways so there is no performance gain.

The MRI image takes care of graphics transformation which might be the same as a scale factor of the screen for the onscreen rendering, but in general, it might be set to any value by the application when rendered to the image.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2875

From serb at openjdk.java.net  Fri May 28 01:47:04 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 28 May 2021 01:47:04 GMT
Subject:  RFR: 8266902: Remove final modifier from static
 methods in swing.text.Utilities
In-Reply-To: 
References: 
Message-ID: 

On Mon, 24 May 2021 18:55:38 GMT, rajat mahajan  wrote:

> Summary: Removed redundant usage of final modifier from static methods in javax.swing.Utilities, since static methods are not inherited and cannot be overridden.

This is not a noop fix, the final keyword in the static method prevents the method to be hidden by the subclass.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4171

From weijun at openjdk.java.net  Fri May 28 02:01:19 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 28 May 2021 02:01:19 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v5]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
Message-ID: 

On Thu, 27 May 2021 20:16:25 GMT, Weijun Wang  wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - move one annotation to new method
>  - merge from master, two files removed, one needs merge
>  - keep only one systemProperty tag
>  - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
>  - feedback from Sean, Phil and Alan
>  - add supresswarnings annotations automatically
>  - manual change before automatic annotating
>  - 8266459: Implement JEP 411: Deprecate the Security Manager for Removal

Two files were removed by JEP 403 and JEP 407, respectively. One method in `XMLSchemaFactory.java` got [its own](https://github.com/openjdk/jdk/commit/8c4719a58834dddcea39d69b199abf1aabf780e2#diff-593a224979eaff03e2a3df1863fcaf865364a31a2212cc0d1fe67a8458057857R429) `@SuppressWarnings` and have to be merged with the one here. Another file `ResourceBundle.java` had a portion of a method extracted into a [new method](https://github.com/openjdk/jdk/commit/a4c46e1e4f4f2f05c8002b2af683a390fc46b424#diff-59caf1a68085064b4b3eb4f6e33e440bb85ea93719f34660970e2d4eaf8ce469R3175) and the annotation must be moved there.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Fri May 28 02:54:05 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 28 May 2021 02:54:05 GMT
Subject:  RFR: 8267521: Post JEP 411 refactoring: maximum
 covering > 50K [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 27 May 2021 17:42:56 GMT, Phil Race  wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update FtpClient.java
>
> src/java.desktop/share/classes/java/awt/Component.java line 630:
> 
>> 628:         }
>> 629: 
>> 630:         @SuppressWarnings("removal")
> 
> I'm confused. I thought the reason this wasn't done in the JEP implementation PR is because of refactoring
> that was needed because of the usage in this static block and you could not apply the annotation here.
> Yet it seems you are doing exactly what was supposed to be impossible with no refactoring.
> Can you explain ?

There *is* a tiny refactoring here: a new variable `s2` is introduced so the 2nd `doPrivileged` call on line 636 is now also in a declaration statement (for `s2`) and therefore annotatable. Without this I cannot add the annotation on line 635.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4138

From prr at openjdk.java.net  Fri May 28 03:15:12 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 28 May 2021 03:15:12 GMT
Subject:  RFR: 8267521: Post JEP 411 refactoring: maximum
 covering > 50K [v3]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Fri, 28 May 2021 02:50:55 GMT, Weijun Wang  wrote:

>> src/java.desktop/share/classes/java/awt/Component.java line 630:
>> 
>>> 628:         }
>>> 629: 
>>> 630:         @SuppressWarnings("removal")
>> 
>> I'm confused. I thought the reason this wasn't done in the JEP implementation PR is because of refactoring
>> that was needed because of the usage in this static block and you could not apply the annotation here.
>> Yet it seems you are doing exactly what was supposed to be impossible with no refactoring.
>> Can you explain ?
>
> There *is* a tiny refactoring here: a new variable `s2` is introduced so the 2nd `doPrivileged` call on line 636 is now also in a declaration statement (for `s2`) and therefore annotatable. Without this I cannot add the annotation on line 635.

Ok. But I will quote you
"This happens when a deprecated method is called inside a static block. The annotation can only be added to a declaration and here it must be the whole class"

So the way you explained this before made it sound like any time there was any SM API usage in a static block, the entire class needed to be annotated.

Why has the explanation changed ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4138

From weijun at openjdk.java.net  Fri May 28 03:22:03 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 28 May 2021 03:22:03 GMT
Subject:  RFR: 8267521: Post JEP 411 refactoring: maximum
 covering > 50K [v3]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Fri, 28 May 2021 03:12:35 GMT, Phil Race  wrote:

>> There *is* a tiny refactoring here: a new variable `s2` is introduced so the 2nd `doPrivileged` call on line 636 is now also in a declaration statement (for `s2`) and therefore annotatable. Without this I cannot add the annotation on line 635.
>
> Ok. But I will quote you
> "This happens when a deprecated method is called inside a static block. The annotation can only be added to a declaration and here it must be the whole class"
> 
> So the way you explained this before made it sound like any time there was any SM API usage in a static block, the entire class needed to be annotated.
> 
> Why has the explanation changed ?

I should have been more precise. An annotation can only be added on a declaration, whether it's a variable, a method, or a class. Static block is not a declaration and the only one covers it is the class. But then if it's on a local variable declaration inside a static block, we certainly can annotate on that variable.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4138

From aivanov at openjdk.java.net  Fri May 28 19:41:28 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 28 May 2021 19:41:28 GMT
Subject:  RFR: 8266902: Remove final modifier from static
 methods in swing.text.Utilities
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 28 May 2021 01:43:41 GMT, Sergey Bylokhov  wrote:

> This is not a noop fix, the final keyword in the static method prevents the method to be hidden by the subclass.

You're right. I've completely forgotten about this feature in Java. When I submitted the issue, I wanted to resolve the warnings from the IDE.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4171

From github.com+79671271+rajamah at openjdk.java.net  Fri May 28 20:19:24 2021
From: github.com+79671271+rajamah at openjdk.java.net (rajat mahajan)
Date: Fri, 28 May 2021 20:19:24 GMT
Subject:  Withdrawn: 8266902: Remove final modifier from static
 methods in swing.text.Utilities
In-Reply-To: 
References: 
Message-ID: 

On Mon, 24 May 2021 18:55:38 GMT, rajat mahajan  wrote:

> Summary: Removed redundant usage of final modifier from static methods in javax.swing.Utilities, since static methods are not inherited and cannot be overridden.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4171

From prr at openjdk.java.net  Sun May 30 17:44:23 2021
From: prr at openjdk.java.net (Phil Race)
Date: Sun, 30 May 2021 17:44:23 GMT
Subject:  RFR: 8267521: Post JEP 411 refactoring: maximum
 covering > 50K [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 21 May 2021 20:37:30 GMT, Weijun Wang  wrote:

>> The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed.
>> 
>> The code change shows some common solutions to avoid such too wide annotations:
>> 
>> 1. Extract calls into a method and add annotation on that method
>> 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value if not void. The local variable will be called `tmp` if later reassigned or `dummy` if it will be discarded.
>> 3. Put declaration and assignment into a single statement if possible.
>> 4. Rewrite code to achieve #3 above.
>> 
>> I'll add a copyright year update commit before integration.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update FtpClient.java

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4138

From weijun at openjdk.java.net  Mon May 31 15:02:57 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 31 May 2021 15:02:57 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v6]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com>

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
> 
> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  default behavior reverted to allow

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4073/files
  - new: https://git.openjdk.java.net/jdk/pull/4073/files/01dc4c0d..8fd09c39

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=04-05

  Stats: 183 lines in 6 files changed: 127 ins; 23 del; 33 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Mon May 31 15:09:27 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 31 May 2021 15:09:27 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v6]
In-Reply-To: <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com>
Message-ID: 

On Mon, 31 May 2021 15:02:57 GMT, Weijun Wang  wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   default behavior reverted to allow

New commit pushed. The default behavior is now reverted to be equivalent to `-Djava.security.manager=allow`. No warning will be shown when the system property is set to "allow", "disallow", or not set. A new test is added to check these warning messages. Some tests are updated to match the new behavior.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From lancea at openjdk.java.net  Mon May 31 16:24:24 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 31 May 2021 16:24:24 GMT
Subject:  RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v6]
In-Reply-To: <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com>
Message-ID: <95Pzw60HuW83TYfd9Dogs6AdG0GDq0Ajh8McoTvRhJU=.37e0db8a-8670-408f-81cd-b5d30ea724ce@github.com>

On Mon, 31 May 2021 15:02:57 GMT, Weijun Wang  wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   default behavior reverted to allow

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073