From naoto at openjdk.java.net Sat May 8 00:03:38 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Sat, 8 May 2021 00:03:38 GMT Subject: RFR: 8266774: System property values for stdout/err on Windows UTF-8 Message-ID: <9jYN7sQh6DrukhjCgUco9DmnHkAqw2W3kb3TlonGLeM=.0cccb7ae-ad98-4453-a0e5-15efa3c71ca1@github.com> Please review this small fix to Windows system property init code. This is leftover from the support for `Console.charset()` method, where it lacked to initialize `sun.stdout/err.encoding` to `UTF-8` for the code page `cp65001`. The fix has been manually verified, but no automated test case is provided, as automatically setting `UTF-8` for the system locale on Windows test machine seems not possible. ------------- Commit messages: - 8266774: System property values for stdout/err on Windows UTF-8 Changes: https://git.openjdk.java.net/jdk/pull/3931/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3931&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266774 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3931.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3931/head:pull/3931 PR: https://git.openjdk.java.net/jdk/pull/3931 From bpb at openjdk.java.net Sat May 8 00:20:22 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Sat, 8 May 2021 00:20:22 GMT Subject: RFR: 8266774: System property values for stdout/err on Windows UTF-8 In-Reply-To: <9jYN7sQh6DrukhjCgUco9DmnHkAqw2W3kb3TlonGLeM=.0cccb7ae-ad98-4453-a0e5-15efa3c71ca1@github.com> References: <9jYN7sQh6DrukhjCgUco9DmnHkAqw2W3kb3TlonGLeM=.0cccb7ae-ad98-4453-a0e5-15efa3c71ca1@github.com> Message-ID: On Fri, 7 May 2021 22:46:08 GMT, Naoto Sato wrote: > Please review this small fix to Windows system property init code. This is leftover from the support for `Console.charset()` method, where it lacked to initialize `sun.stdout/err.encoding` to `UTF-8` for the code page `cp65001`. The fix has been manually verified, but no automated test case is provided, as automatically setting `UTF-8` for the system locale on Windows test machine seems not possible. Looks fine. ------------- Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3931 From alanb at openjdk.java.net Sat May 8 07:17:19 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 8 May 2021 07:17:19 GMT Subject: RFR: 8266774: System property values for stdout/err on Windows UTF-8 In-Reply-To: <9jYN7sQh6DrukhjCgUco9DmnHkAqw2W3kb3TlonGLeM=.0cccb7ae-ad98-4453-a0e5-15efa3c71ca1@github.com> References: <9jYN7sQh6DrukhjCgUco9DmnHkAqw2W3kb3TlonGLeM=.0cccb7ae-ad98-4453-a0e5-15efa3c71ca1@github.com> Message-ID: On Fri, 7 May 2021 22:46:08 GMT, Naoto Sato wrote: > Please review this small fix to Windows system property init code. This is leftover from the support for `Console.charset()` method, where it lacked to initialize `sun.stdout/err.encoding` to `UTF-8` for the code page `cp65001`. The fix has been manually verified, but no automated test case is provided, as automatically setting `UTF-8` for the system locale on Windows test machine seems not possible. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3931 From itakiguchi at openjdk.java.net Sun May 9 14:25:57 2021 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Sun, 9 May 2021 14:25:57 GMT Subject: RFR: 8266013: Unexpected replacement character handling on stateful CharsetEncoder [v2] In-Reply-To: <8MYxd4bq0m2zaz9_M8ty4OcFqCkzDGTcXcRLFbzKdoU=.58825ee2-dd9f-4690-8bdc-8d5955bb7d51@github.com> References: <8MYxd4bq0m2zaz9_M8ty4OcFqCkzDGTcXcRLFbzKdoU=.58825ee2-dd9f-4690-8bdc-8d5955bb7d51@github.com> Message-ID: <94Rf74KQTJDLr-YK0cmH4YSDOMYtbCLILpomr1FlfMA=.150b4787-99fa-4cc3-b08e-e57382f5e28d@github.com> On Fri, 30 Apr 2021 16:11:30 GMT, Ichiroh Takiguchi wrote: >> When an invalid character is converted by getBytes() method, the character is converted to replacement byte data. >> Shift code (SO/SI) may not be added into right place by EBCDIC Mix charset. >> EBCDIC Mix charset encoder is stateful encoder. >> Shift code should be added by switching character set. >> On x-IBM1364, "\u3000\uD800" should be converted to "\x0E\x40\x40\x0F\x6F", but "\x0E\x40\x40\x6F\x0F" >> SI is not in right place. >> >> Also ISO2022 related charsets use escape sequence to switch character set. >> But same kind of issue is there. > > Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: > > 8266013: Unexpected replacement character handling on stateful CharsetEncoder Gentle reminder Currently stateful CharsetEncoder (like EBCDIC Mix, ISO2022 related) cannot handle replacement characters. Please give me your suggestion or advice. ------------- PR: https://git.openjdk.java.net/jdk/pull/3719 From naoto at openjdk.java.net Mon May 10 16:28:54 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 10 May 2021 16:28:54 GMT Subject: Integrated: 8266774: System property values for stdout/err on Windows UTF-8 In-Reply-To: <9jYN7sQh6DrukhjCgUco9DmnHkAqw2W3kb3TlonGLeM=.0cccb7ae-ad98-4453-a0e5-15efa3c71ca1@github.com> References: <9jYN7sQh6DrukhjCgUco9DmnHkAqw2W3kb3TlonGLeM=.0cccb7ae-ad98-4453-a0e5-15efa3c71ca1@github.com> Message-ID: On Fri, 7 May 2021 22:46:08 GMT, Naoto Sato wrote: > Please review this small fix to Windows system property init code. This is leftover from the support for `Console.charset()` method, where it lacked to initialize `sun.stdout/err.encoding` to `UTF-8` for the code page `cp65001`. The fix has been manually verified, but no automated test case is provided, as automatically setting `UTF-8` for the system locale on Windows test machine seems not possible. This pull request has now been integrated. Changeset: c494efc5 Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/c494efc5b5d9a142fceff600285fd4c8c883e795 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8266774: System property values for stdout/err on Windows UTF-8 Reviewed-by: bpb, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/3931 From naoto at openjdk.java.net Mon May 10 23:26:32 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 10 May 2021 23:26:32 GMT Subject: RFR: 8266784: java/text/Collator/RuleBasedCollatorTest.java fails with jtreg 6 Message-ID: Please review this test case fix for the upcoming jtreg 6. The test was using `@BeforeGroups` annotation, and the behavior of it has changed in TestNG 7.1 so that it is only issued when the test was configured with filtering. Changed to use `@BeforeClass` instead. ------------- Commit messages: - 8266784: java/text/Collator/RuleBasedCollatorTest.java fails with jtreg 6 Changes: https://git.openjdk.java.net/jdk/pull/3959/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3959&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266784 Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/3959.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3959/head:pull/3959 PR: https://git.openjdk.java.net/jdk/pull/3959 From joehw at openjdk.java.net Tue May 11 04:27:02 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Tue, 11 May 2021 04:27:02 GMT Subject: RFR: 8266784: java/text/Collator/RuleBasedCollatorTest.java fails with jtreg 6 In-Reply-To: References: Message-ID: On Mon, 10 May 2021 23:12:04 GMT, Naoto Sato wrote: > Please review this test case fix for the upcoming jtreg 6. The test was using `@BeforeGroups` annotation, and the behavior of it has changed in TestNG 7.1 so that it is only issued when the test was configured with filtering. Changed to use `@BeforeClass` instead. Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3959 From naoto at openjdk.java.net Tue May 11 18:13:55 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 11 May 2021 18:13:55 GMT Subject: RFR: 8266013: Unexpected replacement character handling on stateful CharsetEncoder [v2] In-Reply-To: <8MYxd4bq0m2zaz9_M8ty4OcFqCkzDGTcXcRLFbzKdoU=.58825ee2-dd9f-4690-8bdc-8d5955bb7d51@github.com> References: <8MYxd4bq0m2zaz9_M8ty4OcFqCkzDGTcXcRLFbzKdoU=.58825ee2-dd9f-4690-8bdc-8d5955bb7d51@github.com> Message-ID: On Fri, 30 Apr 2021 16:11:30 GMT, Ichiroh Takiguchi wrote: >> When an invalid character is converted by getBytes() method, the character is converted to replacement byte data. >> Shift code (SO/SI) may not be added into right place by EBCDIC Mix charset. >> EBCDIC Mix charset encoder is stateful encoder. >> Shift code should be added by switching character set. >> On x-IBM1364, "\u3000\uD800" should be converted to "\x0E\x40\x40\x0F\x6F", but "\x0E\x40\x40\x6F\x0F" >> SI is not in right place. >> >> Also ISO2022 related charsets use escape sequence to switch character set. >> But same kind of issue is there. > > Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: > > 8266013: Unexpected replacement character handling on stateful CharsetEncoder src/java.base/share/classes/java/nio/charset/Charset-X-Coder.java.template line 632: > 630: if (action == CodingErrorAction.REPLACE) { > 631: #if[encoder] > 632: if (maxBytesPerChar > 3.0) { Does this check imply it is for stateful encoder? Since the fix is for incorrect SO/SI handling, should the fix be localized in those EBCDIC/ISO2022 encoders, not in the generic Charset-X-Coder? ------------- PR: https://git.openjdk.java.net/jdk/pull/3719 From naoto at openjdk.java.net Tue May 11 22:44:58 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 11 May 2021 22:44:58 GMT Subject: Integrated: 8266784: java/text/Collator/RuleBasedCollatorTest.java fails with jtreg 6 In-Reply-To: References: Message-ID: On Mon, 10 May 2021 23:12:04 GMT, Naoto Sato wrote: > Please review this test case fix for the upcoming jtreg 6. The test was using `@BeforeGroups` annotation, and the behavior of it has changed in TestNG 7.1 so that it is only issued when the test was configured with filtering. Changed to use `@BeforeClass` instead. This pull request has now been integrated. Changeset: f6c5a6bb Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/f6c5a6bbf14603c0f4832e5793c48ae1308a7414 Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod 8266784: java/text/Collator/RuleBasedCollatorTest.java fails with jtreg 6 Reviewed-by: joehw ------------- PR: https://git.openjdk.java.net/jdk/pull/3959 From naoto at openjdk.java.net Wed May 12 16:38:48 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 12 May 2021 16:38:48 GMT Subject: RFR: 8258795: Update IANA Language Subtag Registry to Version 2021-05-11 Message-ID: Please review the changes to the subject issue. This is to incorporate the latest language subtag registry definition into the JDK. ------------- Commit messages: - Renaming the test case - LSR 2021-05-11 - LSR 2021-03-05 - LSR 2021-02-23 - LSR 2020-12-18 Changes: https://git.openjdk.java.net/jdk/pull/3998/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3998&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258795 Stats: 340 lines in 2 files changed: 327 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/3998.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3998/head:pull/3998 PR: https://git.openjdk.java.net/jdk/pull/3998 From joehw at openjdk.java.net Thu May 13 01:17:56 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 13 May 2021 01:17:56 GMT Subject: RFR: 8258795: Update IANA Language Subtag Registry to Version 2021-05-11 In-Reply-To: References: Message-ID: On Wed, 12 May 2021 16:28:54 GMT, Naoto Sato wrote: > Please review the changes to the subject issue. This is to incorporate the latest language subtag registry definition into the JDK. Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3998 From naoto at openjdk.java.net Thu May 13 16:24:06 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 13 May 2021 16:24:06 GMT Subject: Integrated: 8258795: Update IANA Language Subtag Registry to Version 2021-05-11 In-Reply-To: References: Message-ID: <1le7MjJnN23bmuhXodlfBpp4-TrVPToGaH_537MA3JY=.3b9c8503-23e0-4278-9705-4d747a7d7c21@github.com> On Wed, 12 May 2021 16:28:54 GMT, Naoto Sato wrote: > Please review the changes to the subject issue. This is to incorporate the latest language subtag registry definition into the JDK. This pull request has now been integrated. Changeset: a259ab4a Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/a259ab4a8d163ff924ba56c5da5395cec0d8c350 Stats: 340 lines in 2 files changed: 327 ins; 0 del; 13 mod 8258795: Update IANA Language Subtag Registry to Version 2021-05-11 Reviewed-by: joehw ------------- PR: https://git.openjdk.java.net/jdk/pull/3998 From naoto at openjdk.java.net Mon May 17 17:08:30 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 17 May 2021 17:08:30 GMT Subject: RFR: 8263202: Update Hebrew/Indonesian/Yiddish ISO 639 language codes to current Message-ID: Please review the changes to the subject issue. java.util.Locale class has a long-standing issue for those obsolete ISO 639 languages where its normalization ends up in the obsolete codes. This change intends to flip the normalization towards the current codes, providing a system property for compatibility behavior. ResourceBundle class is also modified to load either obsolete/current bundles. For more detail, take a look at the CSR. ------------- Commit messages: - Added more ResourceBundleProvider tests - ResourceBundleProvider and test cases modifications - Eliminated some duplicated code - Changed ResourceBundle javadoc - Locale class description - renamed old resource files - inital commit Changes: https://git.openjdk.java.net/jdk/pull/4069/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4069&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263202 Stats: 382 lines in 35 files changed: 239 ins; 41 del; 102 mod Patch: https://git.openjdk.java.net/jdk/pull/4069.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4069/head:pull/4069 PR: https://git.openjdk.java.net/jdk/pull/4069 From erikj at openjdk.java.net Mon May 17 17:17:42 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 17 May 2021 17:17:42 GMT Subject: RFR: 8263202: Update Hebrew/Indonesian/Yiddish ISO 639 language codes to current In-Reply-To: References: Message-ID: <7AIkJPfmGbs8ZppuRu6kDGP4fZXu_RG9t7KEvPLFaJ8=.43150153-f88a-44bd-a903-fe019e2ab9f9@github.com> On Mon, 17 May 2021 16:55:35 GMT, Naoto Sato wrote: > Please review the changes to the subject issue. java.util.Locale class has a long-standing issue for those obsolete ISO 639 languages where its normalization ends up in the obsolete codes. This change intends to flip the normalization towards the current codes, providing a system property for compatibility behavior. ResourceBundle class is also modified to load either obsolete/current bundles. For more detail, take a look at the CSR. I see no relevant build changes to comment on as the build label was only added because the buildtool java source was touched, so this looks ok from a build perspective. ------------- PR: https://git.openjdk.java.net/jdk/pull/4069 From naoto at openjdk.java.net Mon May 17 17:22:37 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 17 May 2021 17:22:37 GMT Subject: RFR: 8263202: Update Hebrew/Indonesian/Yiddish ISO 639 language codes to current In-Reply-To: <7AIkJPfmGbs8ZppuRu6kDGP4fZXu_RG9t7KEvPLFaJ8=.43150153-f88a-44bd-a903-fe019e2ab9f9@github.com> References: <7AIkJPfmGbs8ZppuRu6kDGP4fZXu_RG9t7KEvPLFaJ8=.43150153-f88a-44bd-a903-fe019e2ab9f9@github.com> Message-ID: <2BUKuYhdtpkEUbUG6a-ME_61A1ss_5FN18stfHwI-ic=.9c0b5001-9e65-44c7-ae01-850e751a8180@github.com> On Mon, 17 May 2021 17:14:53 GMT, Erik Joelsson wrote: > I see no relevant build changes to comment on as the build label was only added because the buildtool java source was touched, so this looks ok from a build perspective. Removed `build` label. ------------- PR: https://git.openjdk.java.net/jdk/pull/4069 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 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 pconcannon at openjdk.java.net Tue May 18 10:43:52 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Tue, 18 May 2021 10:43:52 GMT Subject: RFR: 8267110: Update java.util to use instanceof pattern variable Message-ID: Hi, Could someone please review my code for updating the code in the `java.util` package to make use of the `instanceof` pattern variable? Kind regards, Patrick ------------- Commit messages: - 8267110: Update java.util to use instanceof pattern variable Changes: https://git.openjdk.java.net/jdk/pull/4088/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4088&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267110 Stats: 304 lines in 35 files changed: 1 ins; 144 del; 159 mod Patch: https://git.openjdk.java.net/jdk/pull/4088.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4088/head:pull/4088 PR: https://git.openjdk.java.net/jdk/pull/4088 From lancea at openjdk.java.net Tue May 18 11:13:40 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 18 May 2021 11:13:40 GMT Subject: RFR: 8267110: Update java.util to use instanceof pattern variable In-Reply-To: References: Message-ID: On Tue, 18 May 2021 10:37:21 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.util` package to make use of the `instanceof` pattern variable? > > Kind regards, > Patrick Changes look good. ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4088 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 alanb at openjdk.java.net Tue May 18 12:05:38 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 18 May 2021 12:05:38 GMT Subject: RFR: 8267110: Update java.util to use instanceof pattern variable In-Reply-To: References: Message-ID: On Tue, 18 May 2021 10:37:21 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.util` package to make use of the `instanceof` pattern variable? > > Kind regards, > Patrick You may need to coordinate with @DougLea on the changes to j.u.concurrent. ------------- PR: https://git.openjdk.java.net/jdk/pull/4088 From dl at openjdk.java.net Tue May 18 12:23:43 2021 From: dl at openjdk.java.net (Doug Lea) Date: Tue, 18 May 2021 12:23:43 GMT Subject: RFR: 8267110: Update java.util to use instanceof pattern variable In-Reply-To: References: Message-ID: On Tue, 18 May 2021 10:37:21 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.util` package to make use of the `instanceof` pattern variable? > > Kind regards, > Patrick Because we still make jdk11-compatible test-release java.util.concurrent jars, we are not big fans of adding non-essential differences to openjdk version. But if there is some advantage to doing this, we'll cope. ------------- PR: https://git.openjdk.java.net/jdk/pull/4088 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 naoto at openjdk.java.net Tue May 18 16:52:41 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 18 May 2021 16:52:41 GMT Subject: RFR: 8267110: Update java.util to use instanceof pattern variable In-Reply-To: References: Message-ID: On Tue, 18 May 2021 10:37:21 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.util` package to make use of the `instanceof` pattern variable? > > Kind regards, > Patrick Classes in the i18n area look good. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4088 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 joehw at openjdk.java.net Tue May 18 22:53:39 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Tue, 18 May 2021 22:53:39 GMT Subject: RFR: 8263202: Update Hebrew/Indonesian/Yiddish ISO 639 language codes to current In-Reply-To: References: Message-ID: On Mon, 17 May 2021 16:55:35 GMT, Naoto Sato wrote: > Please review the changes to the subject issue. java.util.Locale class has a long-standing issue for those obsolete ISO 639 languages where its normalization ends up in the obsolete codes. This change intends to flip the normalization towards the current codes, providing a system property for compatibility behavior. ResourceBundle class is also modified to load either obsolete/current bundles. For more detail, take a look at the CSR. src/java.base/share/classes/java/util/Locale.java line 462: > 460: * backward compatible forms. > 461: * > 462: *

The APIs added in 1.7 map between the old and new language codes, This paragraph needs a rewrite as well it seems, esp. the part that states "getLanguage and toString reflect the old code" is no longer true. test/jdk/java/util/Locale/LocaleTest.java line 683: > 681: * @bug 4052404 4778440 8263202 > 682: */ > 683: public void TestChangedISO639Codes() { Could probably be simplified with a DataProvider. ------------- PR: https://git.openjdk.java.net/jdk/pull/4069 From naoto at openjdk.java.net Tue May 18 23:39:37 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 18 May 2021 23:39:37 GMT Subject: RFR: 8263202: Update Hebrew/Indonesian/Yiddish ISO 639 language codes to current [v2] In-Reply-To: References: Message-ID: > Please review the changes to the subject issue. java.util.Locale class has a long-standing issue for those obsolete ISO 639 languages where its normalization ends up in the obsolete codes. This change intends to flip the normalization towards the current codes, providing a system property for compatibility behavior. ResourceBundle class is also modified to load either obsolete/current bundles. For more detail, take a look at the CSR. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Locale's class description modification ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4069/files - new: https://git.openjdk.java.net/jdk/pull/4069/files/dee95bf1..0f76ac45 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4069&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4069&range=00-01 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4069.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4069/head:pull/4069 PR: https://git.openjdk.java.net/jdk/pull/4069 From naoto at openjdk.java.net Tue May 18 23:39:42 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 18 May 2021 23:39:42 GMT Subject: RFR: 8263202: Update Hebrew/Indonesian/Yiddish ISO 639 language codes to current [v2] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 22:22:06 GMT, Joe Wang wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Locale's class description modification > > src/java.base/share/classes/java/util/Locale.java line 462: > >> 460: * backward compatible forms. >> 461: * >> 462: *

The APIs added in 1.7 map between the old and new language codes, > > This paragraph needs a rewrite as well it seems, esp. the part that states "getLanguage and toString reflect the old code" is no longer true. Good catch! In fact, I had modified this paragraph in my preliminary fix, but it slipped away somehow along the fix. Corrected the PR and CSR as well. > test/jdk/java/util/Locale/LocaleTest.java line 683: > >> 681: * @bug 4052404 4778440 8263202 >> 682: */ >> 683: public void TestChangedISO639Codes() { > > Could probably be simplified with a DataProvider. That would be nice, but the test is not testng based, and it would be an entire test rewrite which I would not do it at this time. ------------- PR: https://git.openjdk.java.net/jdk/pull/4069 From joehw at openjdk.java.net Wed May 19 06:12:40 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Wed, 19 May 2021 06:12:40 GMT Subject: RFR: 8263202: Update Hebrew/Indonesian/Yiddish ISO 639 language codes to current [v2] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 23:35:12 GMT, Naoto Sato wrote: >> test/jdk/java/util/Locale/LocaleTest.java line 683: >> >>> 681: * @bug 4052404 4778440 8263202 >>> 682: */ >>> 683: public void TestChangedISO639Codes() { >> >> Could probably be simplified with a DataProvider. > > That would be nice, but the test is not testng based, and it would be an entire test rewrite which I would not do it at this time. I see. Good old test is still good. ------------- PR: https://git.openjdk.java.net/jdk/pull/4069 From joehw at openjdk.java.net Wed May 19 06:12:39 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Wed, 19 May 2021 06:12:39 GMT Subject: RFR: 8263202: Update Hebrew/Indonesian/Yiddish ISO 639 language codes to current [v2] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 23:39:37 GMT, Naoto Sato wrote: >> Please review the changes to the subject issue. java.util.Locale class has a long-standing issue for those obsolete ISO 639 languages where its normalization ends up in the obsolete codes. This change intends to flip the normalization towards the current codes, providing a system property for compatibility behavior. ResourceBundle class is also modified to load either obsolete/current bundles. For more detail, take a look at the CSR. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Locale's class description modification Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4069 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 pconcannon at openjdk.java.net Wed May 19 14:08:15 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Wed, 19 May 2021 14:08:15 GMT Subject: RFR: 8267110: Update java.util to use instanceof pattern variable [v2] In-Reply-To: References: Message-ID: <8AXQCx52GlKankpXKO_Ouh0ASaCl9fkiRj8ZCz3TOJo=.85f154c1-0214-4db7-8834-ced49cf4c868@github.com> > Hi, > > Could someone please review my code for updating the code in the `java.util` package to make use of the `instanceof` pattern variable? > > Kind regards, > Patrick Patrick Concannon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - 8267110: Reverted changes in java/util/Formatter as primitive to boxed types may have semantic/performance implications - Merge remote-tracking branch 'origin/master' into JDK-8267110 - 8267110: Update java.util to use instanceof pattern variable ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4088/files - new: https://git.openjdk.java.net/jdk/pull/4088/files/0ed0bd99..cd99dc49 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4088&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4088&range=00-01 Stats: 4003 lines in 175 files changed: 2590 ins; 890 del; 523 mod Patch: https://git.openjdk.java.net/jdk/pull/4088.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4088/head:pull/4088 PR: https://git.openjdk.java.net/jdk/pull/4088 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 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 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 pconcannon at openjdk.java.net Fri May 21 11:26:56 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Fri, 21 May 2021 11:26:56 GMT Subject: RFR: 8267110: Update java.util to use instanceof pattern variable [v3] In-Reply-To: References: Message-ID: > Hi, > > Could someone please review my code for updating the code in the `java.util` package to make use of the `instanceof` pattern variable? > > Kind regards, > Patrick Patrick Concannon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into JDK-8267110 - 8267110: Reverted changes in java/util/Formatter as primitive to boxed types may have semantic/performance implications - Merge remote-tracking branch 'origin/master' into JDK-8267110 - 8267110: Update java.util to use instanceof pattern variable ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4088/files - new: https://git.openjdk.java.net/jdk/pull/4088/files/cd99dc49..da615e7d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4088&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4088&range=01-02 Stats: 4905 lines in 201 files changed: 2421 ins; 2058 del; 426 mod Patch: https://git.openjdk.java.net/jdk/pull/4088.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4088/head:pull/4088 PR: https://git.openjdk.java.net/jdk/pull/4088 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 pconcannon at openjdk.java.net Fri May 21 14:00:43 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Fri, 21 May 2021 14:00:43 GMT Subject: RFR: 8267110: Update java.util to use instanceof pattern variable [v4] In-Reply-To: References: Message-ID: > Hi, > > Could someone please review my code for updating the code in the `java.util` package to make use of the `instanceof` pattern variable? > > Kind regards, > Patrick Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision: 8267110: Reverted changes made to files in java.util.concurrent ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4088/files - new: https://git.openjdk.java.net/jdk/pull/4088/files/da615e7d..2c076a55 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4088&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4088&range=02-03 Stats: 31 lines in 5 files changed: 16 ins; 0 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/4088.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4088/head:pull/4088 PR: https://git.openjdk.java.net/jdk/pull/4088 From github.com+10835776+stsypanov at openjdk.java.net Fri May 21 14:04:23 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 21 May 2021 14:04:23 GMT Subject: RFR: 8263561: Re-examine uses of LinkedList In-Reply-To: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com> References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com> Message-ID: <49DKqYCEGnU3_LyaAoKbyyCrNWeOhpyi06nqfNwqtu0=.3de3c091-0eb1-4d37-881c-f532a6a2e120@github.com> On Fri, 26 Feb 2021 10:48:33 GMT, ?????? ??????? wrote: > The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective. > > jdk:tier1 and jdk:tier2 are both ok Hi guys, any more comments here? Please ping me if I've missed something ------------- PR: https://git.openjdk.java.net/jdk/pull/2744 From alanb at openjdk.java.net Fri May 21 14:26:50 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 21 May 2021 14:26:50 GMT Subject: RFR: 8263561: Re-examine uses of LinkedList In-Reply-To: <49DKqYCEGnU3_LyaAoKbyyCrNWeOhpyi06nqfNwqtu0=.3de3c091-0eb1-4d37-881c-f532a6a2e120@github.com> References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com> <49DKqYCEGnU3_LyaAoKbyyCrNWeOhpyi06nqfNwqtu0=.3de3c091-0eb1-4d37-881c-f532a6a2e120@github.com> Message-ID: <7M39TjBM4Y3jcrY8TSkasy25HcSB8WqKOVu_JK5c4mU=.122ac5e0-50e5-4bf6-80ae-e32337c6938d@github.com> On Fri, 21 May 2021 13:13:04 GMT, ?????? ??????? wrote: > Hi guys, any more comments here? Please ping me if I've missed something I suspect this will require renaming some fields and changing comments, e.g. requestList is no longer a good name for the field in AbstractPoller, its comments need changes too. The field in ResolverConfigurationImpl is searchList, it will require a few changes. There may be more, I just picked out a few. ------------- PR: https://git.openjdk.java.net/jdk/pull/2744 From dfuchs at openjdk.java.net Fri May 21 14:26:48 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 21 May 2021 14:26:48 GMT Subject: RFR: 8263561: Re-examine uses of LinkedList In-Reply-To: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com> References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com> Message-ID: On Fri, 26 Feb 2021 10:48:33 GMT, ?????? ??????? wrote: > The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective. > > jdk:tier1 and jdk:tier2 are both ok I don't remember all the comments you have received in this thread but have you verified that arbitrarily changing `LinkedList` into `ArrayList` in these classes is not going to significantly increase the footprint in the case where lists are empty or contain only one or two elements? I am not convinced that a global replacement of `LinkedList` by `ArrayList` is necessarily good - even though I agree that `ArrayList` is generally more efficient. src/java.base/share/classes/jdk/internal/util/jar/JarIndex.java line 155: > 153: */ > 154: public List get(String fileName) { > 155: ArrayList jarFiles; This could probably be declared as: List jarFiles; src/java.base/share/classes/jdk/internal/util/jar/JarIndex.java line 264: > 262: String jar = jarFiles[i]; > 263: bw.write(jar + "\n"); > 264: ArrayList jarlist = jarMap.get(jar); Here again, jarList could probably be declared as `List` ------------- PR: https://git.openjdk.java.net/jdk/pull/2744 From github.com+13357965+thihup at openjdk.java.net Fri May 21 14:55:16 2021 From: github.com+13357965+thihup at openjdk.java.net (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=) Date: Fri, 21 May 2021 14:55:16 GMT Subject: RFR: 8263561: Re-examine uses of LinkedList In-Reply-To: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com> References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com> Message-ID: On Fri, 26 Feb 2021 10:48:33 GMT, ?????? ??????? wrote: > The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective. > > jdk:tier1 and jdk:tier2 are both ok src/java.base/share/classes/jdk/internal/util/jar/JarIndex.java line 154: > 152: * @param fileName the key of the mapping > 153: */ > 154: public List get(String fileName) { IcedTea-Web seems to be using this method reflectively: https://github.com/AdoptOpenJDK/IcedTea-Web/blob/master/common/src/main/java/net/adoptopenjdk/icedteaweb/jdk89access/JarIndexAccess.java#L80 ------------- PR: https://git.openjdk.java.net/jdk/pull/2744 From alanb at openjdk.java.net Fri May 21 15:02:57 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 21 May 2021 15:02:57 GMT Subject: RFR: 8263561: Re-examine uses of LinkedList In-Reply-To: References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com> Message-ID: On Fri, 21 May 2021 14:52:21 GMT, Thiago Henrique H?pner wrote: > IcedTea-Web seems to be using this method reflectively: > https://github.com/AdoptOpenJDK/IcedTea-Web/blob/master/common/src/main/java/net/adoptopenjdk/icedteaweb/jdk89access/JarIndexAccess.java#L80 I assume this doesn't work with JDK 16, at least not without using --add-options to export jdk.internal.util.jar. ------------- PR: https://git.openjdk.java.net/jdk/pull/2744 From github.com+13357965+thihup at openjdk.java.net Fri May 21 15:15:15 2021 From: github.com+13357965+thihup at openjdk.java.net (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=) Date: Fri, 21 May 2021 15:15:15 GMT Subject: RFR: 8263561: Re-examine uses of LinkedList In-Reply-To: References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com> Message-ID: On Fri, 21 May 2021 15:00:15 GMT, Alan Bateman wrote: >> src/java.base/share/classes/jdk/internal/util/jar/JarIndex.java line 154: >> >>> 152: * @param fileName the key of the mapping >>> 153: */ >>> 154: public List get(String fileName) { >> >> IcedTea-Web seems to be using this method reflectively: >> https://github.com/AdoptOpenJDK/IcedTea-Web/blob/master/common/src/main/java/net/adoptopenjdk/icedteaweb/jdk89access/JarIndexAccess.java#L80 > >> IcedTea-Web seems to be using this method reflectively: >> https://github.com/AdoptOpenJDK/IcedTea-Web/blob/master/common/src/main/java/net/adoptopenjdk/icedteaweb/jdk89access/JarIndexAccess.java#L80 > > I assume this doesn't work with JDK 16, at least not without using --add-options to export jdk.internal.util.jar. Just for completeness, they're using the add-exports: https://github.com/AdoptOpenJDK/IcedTea-Web/blob/master/launchers/itw-modularjdk.args#L19 ------------- PR: https://git.openjdk.java.net/jdk/pull/2744 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 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 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 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 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 mcimadamore at openjdk.java.net Fri May 21 23:20:04 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 21 May 2021 23:20:04 GMT Subject: RFR: 8263561: Re-examine uses of LinkedList In-Reply-To: References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com> Message-ID: On Fri, 21 May 2021 14:22:47 GMT, Daniel Fuchs wrote: >> The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective. >> >> jdk:tier1 and jdk:tier2 are both ok > > I don't remember all the comments you have received in this thread but have you verified that arbitrarily changing `LinkedList` into `ArrayList` in these classes is not going to significantly increase the footprint in the case where lists are empty or contain only one or two elements? > > I am not convinced that a global replacement of `LinkedList` by `ArrayList` is necessarily good - even though I agree that `ArrayList` is generally more efficient. I second the footprint concerns from @dfuch. I've seen with first hand cases where widespread uses of array lists for holding 1-2-3 elements (e.g. think of a graph where each node might only have a very small number of outgoing edges) lead to massive memory over-utilization. If the average size is known, at the very least I'd argue to replace with an array list which is sized correctly. And, all this said, the general assumption implied in this PR which linked lists are just to be avoided doesn't match my experience. If you want a "pay only as much memory as you use" data structure, you don't care about random access (e.g. all accesses are linear walks), a linked list is a perfectly fine choice. If there are use cases in the JDK where a LinkedList is used in places where it shouldn't be, then obviously _those cases_ should be replaced. ------------- PR: https://git.openjdk.java.net/jdk/pull/2744 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 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 tvaleev at openjdk.java.net Mon May 24 04:33:42 2021 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Mon, 24 May 2021 04:33:42 GMT Subject: RFR: 8267587: Update java.util to use enhanced switch In-Reply-To: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> Message-ID: On Mon, 24 May 2021 04:20:23 GMT, Tagir F. Valeev wrote: > Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc. > > I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement? src/java.base/share/classes/java/util/jar/JarFile.java line 201: > 199: MULTI_RELEASE_FORCED = true; > 200: } > 201: default -> { Here, explicit `case "true"` disappeared. Not sure if it's important to keep it. ------------- PR: https://git.openjdk.java.net/jdk/pull/4161 From tvaleev at openjdk.java.net Mon May 24 04:33:40 2021 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Mon, 24 May 2021 04:33:40 GMT Subject: RFR: 8267587: Update java.util to use enhanced switch Message-ID: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc. I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement? ------------- Commit messages: - 8267587: Update java.util to use enhanced switch Changes: https://git.openjdk.java.net/jdk/pull/4161/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4161&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267587 Stats: 887 lines in 17 files changed: 113 ins; 339 del; 435 mod Patch: https://git.openjdk.java.net/jdk/pull/4161.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4161/head:pull/4161 PR: https://git.openjdk.java.net/jdk/pull/4161 From github.com+10835776+stsypanov at openjdk.java.net Mon May 24 07:04:05 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 24 May 2021 07:04:05 GMT Subject: RFR: 8263561: Re-examine uses of LinkedList In-Reply-To: References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com> Message-ID: On Fri, 21 May 2021 14:15:53 GMT, Daniel Fuchs wrote: >> The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective. >> >> jdk:tier1 and jdk:tier2 are both ok > > src/java.base/share/classes/jdk/internal/util/jar/JarIndex.java line 155: > >> 153: */ >> 154: public List get(String fileName) { >> 155: ArrayList jarFiles; > > This could probably be declared as: > > > List jarFiles; Done ------------- PR: https://git.openjdk.java.net/jdk/pull/2744 From github.com+10835776+stsypanov at openjdk.java.net Mon May 24 07:10:40 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 24 May 2021 07:10:40 GMT Subject: RFR: 8263561: Re-examine uses of LinkedList In-Reply-To: References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com> Message-ID: On Fri, 21 May 2021 14:18:16 GMT, Daniel Fuchs wrote: >> The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective. >> >> jdk:tier1 and jdk:tier2 are both ok > > src/java.base/share/classes/jdk/internal/util/jar/JarIndex.java line 264: > >> 262: String jar = jarFiles[i]; >> 263: bw.write(jar + "\n"); >> 264: ArrayList jarlist = jarMap.get(jar); > > Here again, jarList could probably be declared as `List` Done ------------- PR: https://git.openjdk.java.net/jdk/pull/2744 From github.com+10835776+stsypanov at openjdk.java.net Mon May 24 07:17:08 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 24 May 2021 07:17:08 GMT Subject: RFR: 8263561: Re-examine uses of LinkedList In-Reply-To: References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com> Message-ID: On Fri, 21 May 2021 15:12:20 GMT, Thiago Henrique H?pner wrote: >>> IcedTea-Web seems to be using this method reflectively: >>> https://github.com/AdoptOpenJDK/IcedTea-Web/blob/master/common/src/main/java/net/adoptopenjdk/icedteaweb/jdk89access/JarIndexAccess.java#L80 >> >> I assume this doesn't work with JDK 16, at least not without using --add-exports to export jdk.internal.util.jar. > > Just for completeness, they're using the add-exports: > https://github.com/AdoptOpenJDK/IcedTea-Web/blob/master/launchers/itw-modularjdk.args#L19 Should we then revert the changes to `JarIndex`? ------------- PR: https://git.openjdk.java.net/jdk/pull/2744 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 github.com+7806504+liach at openjdk.java.net Mon May 24 09:28:15 2021 From: github.com+7806504+liach at openjdk.java.net (liach) Date: Mon, 24 May 2021 09:28:15 GMT Subject: RFR: 8263561: Re-examine uses of LinkedList In-Reply-To: References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com> Message-ID: On Mon, 24 May 2021 07:13:29 GMT, ?????? ??????? wrote: >> Just for completeness, they're using the add-exports: >> https://github.com/AdoptOpenJDK/IcedTea-Web/blob/master/launchers/itw-modularjdk.args#L19 > > Should we then revert the changes to `JarIndex`? But don't people access these internal code at their own risk, as jdk may change these code at any time without notice? ------------- PR: https://git.openjdk.java.net/jdk/pull/2744 From github.com+10835776+stsypanov at openjdk.java.net Mon May 24 10:17:19 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 24 May 2021 10:17:19 GMT Subject: RFR: 8263561: Re-examine uses of LinkedList In-Reply-To: References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com> Message-ID: On Mon, 24 May 2021 09:25:08 GMT, liach wrote: >> Should we then revert the changes to `JarIndex`? > > But don't people access these internal code at their own risk, as jdk may change these code at any time without notice? True, I just wonder whether it's OK to change internals when we know for sure that this breaks 3rd party code ------------- PR: https://git.openjdk.java.net/jdk/pull/2744 From github.com+7806504+liach at openjdk.java.net Mon May 24 12:11:38 2021 From: github.com+7806504+liach at openjdk.java.net (liach) Date: Mon, 24 May 2021 12:11:38 GMT Subject: RFR: 8263561: Re-examine uses of LinkedList In-Reply-To: References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com> Message-ID: On Mon, 24 May 2021 10:13:55 GMT, ?????? ??????? wrote: >> But don't people access these internal code at their own risk, as jdk may change these code at any time without notice? > > True, I just wonder whether it's OK to change internals when we know for sure that this breaks 3rd party code I think so. There are always unexpected ways the jdk may break and third-party libraries would need a different workaround for a new java version. For instance, in Apache log4j, its library has a special guard against the broken implementation of Reflection getCallerClass during java 7. The libraries can just handle these in their version-specific components. Especially given the fact that the code linked above already has version-specific handling (8 vs 9), so it won't hurt much for them to add another piece of logic to handle jdk 17+ in case this optimization is merged. ------------- PR: https://git.openjdk.java.net/jdk/pull/2744 From pconcannon at openjdk.java.net Mon May 24 13:44:41 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Mon, 24 May 2021 13:44:41 GMT Subject: RFR: 8267110: Update java.util to use instanceof pattern variable [v5] In-Reply-To: References: Message-ID: > Hi, > > Could someone please review my code for updating the code in the `java.util` package to make use of the `instanceof` pattern variable? > > Kind regards, > Patrick Patrick Concannon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into JDK-8267110 - 8267110: Reverted changes made to files in java.util.concurrent - Merge remote-tracking branch 'origin/master' into JDK-8267110 - 8267110: Reverted changes in java/util/Formatter as primitive to boxed types may have semantic/performance implications - Merge remote-tracking branch 'origin/master' into JDK-8267110 - 8267110: Update java.util to use instanceof pattern variable ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4088/files - new: https://git.openjdk.java.net/jdk/pull/4088/files/2c076a55..9bca9400 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4088&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4088&range=03-04 Stats: 1931 lines in 65 files changed: 1061 ins; 429 del; 441 mod Patch: https://git.openjdk.java.net/jdk/pull/4088.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4088/head:pull/4088 PR: https://git.openjdk.java.net/jdk/pull/4088 From dfuchs at openjdk.java.net Mon May 24 13:50:12 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 24 May 2021 13:50:12 GMT Subject: RFR: 8267587: Update java.util to use enhanced switch In-Reply-To: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> Message-ID: On Mon, 24 May 2021 04:20:23 GMT, Tagir F. Valeev wrote: > Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc. > > I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement? src/java.base/share/classes/java/util/regex/CharPredicates.java line 217: > 215: case "WORD" -> WORD(); > 216: default -> null; > 217: }; This file has lots of changes which are difficult to review. Maybe it should be split out of this PR. src/java.base/share/classes/java/util/zip/ZipOutputStream.java line 261: > 259: ZipEntry e = current.entry; > 260: switch (e.method) { > 261: case DEFLATED -> { Same remark here - it's not clear what's going on. ------------- PR: https://git.openjdk.java.net/jdk/pull/4161 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 tvaleev at openjdk.java.net Tue May 25 03:52:06 2021 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Tue, 25 May 2021 03:52:06 GMT Subject: RFR: 8267587: Update java.util to use enhanced switch In-Reply-To: References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> Message-ID: <4cPrOLZV8ybO_73OiaHFo3Yt8TwSRoJYvFMzeOBMQMo=.0c03c713-d4f8-4631-b485-e5f4d0441374@github.com> On Mon, 24 May 2021 13:44:36 GMT, Daniel Fuchs wrote: >> Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc. >> >> I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement? > > src/java.base/share/classes/java/util/regex/CharPredicates.java line 217: > >> 215: case "WORD" -> WORD(); >> 216: default -> null; >> 217: }; > > This file has lots of changes which are difficult to review. Maybe it should be split out of this PR. *sigh* GitHub diff tool is really poor and outdated. Here's how it looks in IntelliJ IDEA diff view: ![image](https://user-images.githubusercontent.com/5114450/119436474-6b455b80-bd46-11eb-8865-8b7f30826a8d.png) ------------- PR: https://git.openjdk.java.net/jdk/pull/4161 From tvaleev at openjdk.java.net Tue May 25 03:56:07 2021 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Tue, 25 May 2021 03:56:07 GMT Subject: RFR: 8267587: Update java.util to use enhanced switch In-Reply-To: References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> Message-ID: On Mon, 24 May 2021 13:46:58 GMT, Daniel Fuchs wrote: >> Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc. >> >> I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement? > > src/java.base/share/classes/java/util/zip/ZipOutputStream.java line 261: > >> 259: ZipEntry e = current.entry; >> 260: switch (e.method) { >> 261: case DEFLATED -> { > > Same remark here - it's not clear what's going on. Here, it's mostly indentation change (+4 spaces). You can set "Hide whitespace changes" and see: ![image](https://user-images.githubusercontent.com/5114450/119436860-3259b680-bd47-11eb-92d8-f940493d08c2.png) Alternatively, I can indent back this switch, placing `case` on the same indentation level as `switch`. I'm not sure about recommended code style in OpenJDK project, it looks like it's not very consistent. ------------- PR: https://git.openjdk.java.net/jdk/pull/4161 From tvaleev at openjdk.java.net Tue May 25 04:13:36 2021 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Tue, 25 May 2021 04:13:36 GMT Subject: RFR: 8267587: Update java.util to use enhanced switch [v2] In-Reply-To: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> Message-ID: > Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc. > > I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement? Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: Unindent switch cases to simplify the review ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4161/files - new: https://git.openjdk.java.net/jdk/pull/4161/files/807d780d..2e966d0f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4161&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4161&range=00-01 Stats: 64 lines in 1 file changed: 27 ins; 27 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/4161.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4161/head:pull/4161 PR: https://git.openjdk.java.net/jdk/pull/4161 From tvaleev at openjdk.java.net Tue May 25 06:01:49 2021 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Tue, 25 May 2021 06:01:49 GMT Subject: RFR: 8267587: Update java.util to use enhanced switch [v3] In-Reply-To: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> Message-ID: <78LopXMnM-8NJkcJRbMIcJFSzAEpOvyOXuhA_4vr9gg=.3a1ed69b-99e0-4a0a-912f-57a861decd2d@github.com> > Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc. > > I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement? Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: Indent some lines to make GitHub diff happier ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4161/files - new: https://git.openjdk.java.net/jdk/pull/4161/files/2e966d0f..07a998bc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4161&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4161&range=01-02 Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/4161.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4161/head:pull/4161 PR: https://git.openjdk.java.net/jdk/pull/4161 From tvaleev at openjdk.java.net Tue May 25 06:06:05 2021 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Tue, 25 May 2021 06:06:05 GMT Subject: RFR: 8267587: Update java.util to use enhanced switch [v3] In-Reply-To: <4cPrOLZV8ybO_73OiaHFo3Yt8TwSRoJYvFMzeOBMQMo=.0c03c713-d4f8-4631-b485-e5f4d0441374@github.com> References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> <4cPrOLZV8ybO_73OiaHFo3Yt8TwSRoJYvFMzeOBMQMo=.0c03c713-d4f8-4631-b485-e5f4d0441374@github.com> Message-ID: On Tue, 25 May 2021 03:48:41 GMT, Tagir F. Valeev wrote: >> src/java.base/share/classes/java/util/regex/CharPredicates.java line 217: >> >>> 215: case "WORD" -> WORD(); >>> 216: default -> null; >>> 217: }; >> >> This file has lots of changes which are difficult to review. Maybe it should be split out of this PR. > > *sigh* GitHub diff tool is really poor and outdated. Here's how it looks in IntelliJ IDEA diff view: > ![image](https://user-images.githubusercontent.com/5114450/119436474-6b455b80-bd46-11eb-8865-8b7f30826a8d.png) I played with indentations and found a way to make GitHub diff happier. Now, lines like `? UPPERCASE().union(LOWERCASE(), TITLECASE())` are probably a little bit too far to the right but it's still acceptable and diff looks much easier to review now. ------------- PR: https://git.openjdk.java.net/jdk/pull/4161 From github.com+10835776+stsypanov at openjdk.java.net Tue May 25 07:45:32 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Tue, 25 May 2021 07:45:32 GMT Subject: RFR: 8263561: Re-examine uses of LinkedList [v2] In-Reply-To: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com> References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com> Message-ID: > The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective. > > jdk:tier1 and jdk:tier2 are both ok ?????? ??????? has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains three new commits since the last revision: - 8263561: Use interface List instead of particular type where possible - 8263561: Rename requestList -> requests - 8263561: Re-examine uses of LinkedList ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2744/files - new: https://git.openjdk.java.net/jdk/pull/2744/files/73029fe1..158006c6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2744&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2744&range=00-01 Stats: 17 lines in 2 files changed: 0 ins; 0 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/2744.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2744/head:pull/2744 PR: https://git.openjdk.java.net/jdk/pull/2744 From pconcannon at openjdk.java.net Tue May 25 08:28:10 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Tue, 25 May 2021 08:28:10 GMT Subject: Integrated: 8267110: Update java.util to use instanceof pattern variable In-Reply-To: References: Message-ID: On Tue, 18 May 2021 10:37:21 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.util` package to make use of the `instanceof` pattern variable? > > Kind regards, > Patrick This pull request has now been integrated. Changeset: a52c4ede Author: Patrick Concannon URL: https://git.openjdk.java.net/jdk/commit/a52c4ede2f043b7d4a234c7d06f91871312e9654 Stats: 267 lines in 29 files changed: 1 ins; 125 del; 141 mod 8267110: Update java.util to use instanceof pattern variable Reviewed-by: lancea, naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/4088 From pconcannon at openjdk.java.net Tue May 25 10:36:00 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Tue, 25 May 2021 10:36:00 GMT Subject: RFR: 8267587: Update java.util to use enhanced switch [v3] In-Reply-To: <78LopXMnM-8NJkcJRbMIcJFSzAEpOvyOXuhA_4vr9gg=.3a1ed69b-99e0-4a0a-912f-57a861decd2d@github.com> References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> <78LopXMnM-8NJkcJRbMIcJFSzAEpOvyOXuhA_4vr9gg=.3a1ed69b-99e0-4a0a-912f-57a861decd2d@github.com> Message-ID: On Tue, 25 May 2021 06:01:49 GMT, Tagir F. Valeev wrote: >> Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc. >> >> I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement? > > Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: > > Indent some lines to make GitHub diff happier src/java.base/share/classes/java/util/GregorianCalendar.java line 1730: > 1728: int value = -1; > 1729: switch (field) { > 1730: case MONTH -> { HI @amaembo, thanks for taking a look at this. I think you should be careful here, and ask is introducing the enchanced switch adding any value? While I think the enchanced switch can be valuable when it makes the code more readable, it shouldn't be introduced just for the sake of using it. src/java.base/share/classes/java/util/PropertyPermission.java line 337: > 335: */ > 336: static String getActions(int mask) { > 337: return switch (mask & (READ | WRITE)) { Just a suggestion, but it might be more readable if you align the lambda operators ------------- PR: https://git.openjdk.java.net/jdk/pull/4161 From tvaleev at openjdk.java.net Tue May 25 11:39:02 2021 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Tue, 25 May 2021 11:39:02 GMT Subject: RFR: 8267587: Update java.util to use enhanced switch [v4] In-Reply-To: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> Message-ID: > Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc. > > I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement? Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: Vertical alignment for single-line switch rules ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4161/files - new: https://git.openjdk.java.net/jdk/pull/4161/files/07a998bc..82f40605 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4161&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4161&range=02-03 Stats: 54 lines in 10 files changed: 2 ins; 0 del; 52 mod Patch: https://git.openjdk.java.net/jdk/pull/4161.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4161/head:pull/4161 PR: https://git.openjdk.java.net/jdk/pull/4161 From tvaleev at openjdk.java.net Tue May 25 11:39:45 2021 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Tue, 25 May 2021 11:39:45 GMT Subject: RFR: 8267587: Update java.util to use enhanced switch [v3] In-Reply-To: References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> <78LopXMnM-8NJkcJRbMIcJFSzAEpOvyOXuhA_4vr9gg=.3a1ed69b-99e0-4a0a-912f-57a861decd2d@github.com> Message-ID: On Tue, 25 May 2021 10:31:33 GMT, Patrick Concannon wrote: >> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: >> >> Indent some lines to make GitHub diff happier > > src/java.base/share/classes/java/util/GregorianCalendar.java line 1730: > >> 1728: int value = -1; >> 1729: switch (field) { >> 1730: case MONTH -> { > > HI @amaembo, thanks for taking a look at this. > > I think you should be careful here, and ask is introducing the enchanced switch adding any value? While I think the enchanced switch can be valuable when it makes the code more readable, it shouldn't be introduced just for the sake of using it. @pconcannon thank you for review! In this particular place, it makes the code more better in the following points: - It removes `break;` operators at the end of each branch, which add nothing but a visual noise - It makes the whole switch shorter by 22 lines - Using `->` syntax clearly states that no branch in this switch has a fall-through behavior, so the code reader should not check every branch to ensure this. Just see very first `->` and you already know that no fallthrough is here. - In case if new branches will appear in the future, the new-style switch will protect future maintainers from accidental fall-through, an error that often happens with old-style switches. > src/java.base/share/classes/java/util/PropertyPermission.java line 337: > >> 335: */ >> 336: static String getActions(int mask) { >> 337: return switch (mask & (READ | WRITE)) { > > Just a suggestion, but it might be more readable if you align the lambda operators Thank you for pointing to this. Actually, I just noticed that there was some kind of vertical alignment before my change. I added vertical alignment for single-line switch rules. ------------- PR: https://git.openjdk.java.net/jdk/pull/4161 From github.com+10835776+stsypanov at openjdk.java.net Tue May 25 11:42:41 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Tue, 25 May 2021 11:42:41 GMT Subject: RFR: 8263561: Re-examine uses of LinkedList [v2] In-Reply-To: References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com> Message-ID: On Fri, 21 May 2021 23:16:57 GMT, Maurizio Cimadamore wrote: >> I don't remember all the comments you have received in this thread but have you verified that arbitrarily changing `LinkedList` into `ArrayList` in these classes is not going to significantly increase the footprint in the case where lists are empty or contain only one or two elements? >> >> I am not convinced that a global replacement of `LinkedList` by `ArrayList` is necessarily good - even though I agree that `ArrayList` is generally more efficient. > > I second the footprint concerns from @dfuch. I've seen with first hand cases where widespread uses of array lists for holding 1-2-3 elements (e.g. think of a graph where each node might only have a very small number of outgoing edges) lead to massive memory over-utilization. If the average size is known, at the very least I'd argue to replace with an array list which is sized correctly. > > And, all this said, the general assumption implied in this PR which linked lists are just to be avoided doesn't match my experience. If you want a "pay only as much memory as you use" data structure, you don't care about random access (e.g. all accesses are linear walks), a linked list is a perfectly fine choice. If there are use cases in the JDK where a LinkedList is used in places where it shouldn't be, then obviously _those cases_ should be replaced. Hi @mcimadamore, @dfuch after your review comments I've decided to do a deeper investigation for this. First, I've decided to check whether empty `LinkedList` is going to have smaller footprint (this could be fruitful for cases when the list is likely to remain empty in vast majority of cases, see e.g. `URLClassPath.closeLoaders()`), and apparently it isn't: @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) public class EmptyListBenchmark { @Benchmark public Object emptyArrayList() { return new ArrayList<>(); } @Benchmark public Object emptyLinkedList() { return new LinkedList<>(); } } This benchmark with my ad-hoc JDK build yields the following results: Benchmark Mode Cnt Score Error Units EmptyListBenchmark.emptyArrayList avgt 20 4.605 ? 0.463 ns/op EmptyListBenchmark.emptyArrayList:?gc.alloc.rate.norm avgt 20 24.002 ? 0.001 B/op EmptyListBenchmark.emptyLinkedList avgt 20 4.324 ? 0.081 ns/op EmptyListBenchmark.emptyLinkedList:?gc.alloc.rate.norm avgt 20 32.002 ? 0.001 B/op After JDK-8011200 `ArrayList` instantiated with default constructor doesn't allocate underlying array any more. However the things get more complicated when the list gets populated: @State(Scope.Thread) @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) public class NonEmptyListBenchmark { @Param({"1", "2", "3", "4", "5"}) private int size; @Benchmark public Object arrayList() { var list = new ArrayList<>(); for (int i = 0; i < size; i++) { list.add(i); } return list; } @Benchmark public Object linkedList() { var list = new LinkedList(); for (int i = 0; i < size; i++) { list.add(i); } return list; } } Here indeed `ArrayList` looses in memory comapring to `LinkedList` in single-item case: arrayList:?gc.alloc.rate.norm 1 avgt 40 80.005 ? 0.001 B/op arrayList:?gc.alloc.rate.norm 2 avgt 40 80.006 ? 0.001 B/op arrayList:?gc.alloc.rate.norm 3 avgt 40 80.007 ? 0.001 B/op arrayList:?gc.alloc.rate.norm 4 avgt 40 80.008 ? 0.001 B/op arrayList:?gc.alloc.rate.norm 5 avgt 40 80.008 ? 0.001 B/op linkedList:?gc.alloc.rate.norm 1 avgt 40 56.004 ? 0.001 B/op linkedList:?gc.alloc.rate.norm 2 avgt 40 80.005 ? 0.001 B/op linkedList:?gc.alloc.rate.norm 3 avgt 40 104.007 ? 0.001 B/op linkedList:?gc.alloc.rate.norm 4 avgt 40 128.009 ? 0.001 B/op linkedList:?gc.alloc.rate.norm 5 avgt 40 152.010 ? 0.001 B/op And indeed there's at least one usecase in affected files where this is real-life scenario - `JarIndex`. Below on screenshot I run Spring Boot tests with Gradle: ![image](https://d.radikal.ru/d26/2105/d0/a5d588f282e6.png) However, for the same scenario one node represented with `LinkedList` can hold dozens of items: ![image](https://c.radikal.ru/c38/2105/da/80e6a78cec08.png) To fix this I propose to instantiate `ArrayList` with initial size = 1: @Benchmark public Object arrayList_sized() { var list = new ArrayList<>(1); list.add(new Object()); return list; } This reduces the footprint of a list with 1 element down to 48 bytes: arrayList_sized:?gc.alloc.rate.norm 1 avgt 40 48.004 ? 0.001 B/op ------------- PR: https://git.openjdk.java.net/jdk/pull/2744 From tvaleev at openjdk.java.net Tue May 25 11:49:18 2021 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Tue, 25 May 2021 11:49:18 GMT Subject: RFR: 8267587: Update java.util to use enhanced switch [v5] In-Reply-To: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> Message-ID: > Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc. > > I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement? Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: More vertical alignment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4161/files - new: https://git.openjdk.java.net/jdk/pull/4161/files/82f40605..f4ad5f14 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4161&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4161&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4161.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4161/head:pull/4161 PR: https://git.openjdk.java.net/jdk/pull/4161 From pconcannon at openjdk.java.net Tue May 25 11:57:26 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Tue, 25 May 2021 11:57:26 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions Message-ID: Hi, Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? Kind regards, Patrick ------------- Commit messages: - 8267670: Update java.io, java.math, and java.text to use switch expressions Changes: https://git.openjdk.java.net/jdk/pull/4182/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4182&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267670 Stats: 328 lines in 11 files changed: 1 ins; 187 del; 140 mod Patch: https://git.openjdk.java.net/jdk/pull/4182.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4182/head:pull/4182 PR: https://git.openjdk.java.net/jdk/pull/4182 From github.com+10835776+stsypanov at openjdk.java.net Tue May 25 12:03:29 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Tue, 25 May 2021 12:03:29 GMT Subject: RFR: 8263561: Re-examine uses of LinkedList [v3] In-Reply-To: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com> References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com> Message-ID: > The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective. > > jdk:tier1 and jdk:tier2 are both ok ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: 8263561: Use sized constructor where reasonable ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2744/files - new: https://git.openjdk.java.net/jdk/pull/2744/files/158006c6..40910fae Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2744&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2744&range=01-02 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2744.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2744/head:pull/2744 PR: https://git.openjdk.java.net/jdk/pull/2744 From chegar at openjdk.java.net Tue May 25 12:34:55 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Tue, 25 May 2021 12:34:55 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions In-Reply-To: References: Message-ID: <3RO89K_OHLuQJPiDTPNMTppqvW2W_U1OeQWEwJvn56U=.c3331ce0-4617-40f9-b542-adeaf9c007b6@github.com> On Tue, 25 May 2021 09:37:58 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? > > Kind regards, > Patrick src/java.base/share/classes/java/io/ObjectInputStream.java line 1877: > 1875: descriptor.checkInitialized(); > 1876: } > 1877: default -> throw new StreamCorruptedException( What would you think of assigning descriptor with the value returned from evaluating the switch? Either: 1) ObjectStreamClass descriptor = switch (tc) { case TC_NULL -> (ObjectStreamClass) readNull(); case TC_PROXYCLASSDESC -> readProxyDesc(unshared); case TC_CLASSDESC -> readNonProxyDesc(unshared); case TC_REFERENCE -> readAndCheckHandle(unshared); default -> throw new StreamCorruptedException(String.format("invalid type code: %02X", tc)); }; return descriptor; } , where the body of TC_REFERENCE is enclosed in readAndCheckHandle, OR 2) Simply case TC_REFERENCE -> { var d = (ObjectStreamClass)readHandle(unshared); // Should only reference initialized class descriptors d.checkInitialized(); yield d; } ------------- PR: https://git.openjdk.java.net/jdk/pull/4182 From naoto at openjdk.java.net Tue May 25 12:47:11 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 25 May 2021 12:47:11 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions In-Reply-To: References: Message-ID: On Tue, 25 May 2021 09:37:58 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? > > Kind regards, > Patrick src/java.base/share/classes/java/text/BreakIterator.java line 569: > 567: case SENTENCE_INDEX -> breakIteratorProvider.getSentenceInstance(locale); > 568: default -> null; > 569: }; No need to use the local variable `iterator` here. Simply return with the switch expression. src/java.base/share/classes/java/text/NumberFormat.java line 982: > 980: case COMPACTSTYLE -> provider.getCompactNumberInstance(locale, formatStyle); > 981: default -> null; > 982: }; Same as `BreakIterator`. No need for `numberFormat`. ------------- PR: https://git.openjdk.java.net/jdk/pull/4182 From chegar at openjdk.java.net Tue May 25 13:00:01 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Tue, 25 May 2021 13:00:01 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions In-Reply-To: References: Message-ID: <-mfOzgikw-2iSXIjdLfI0bOEzgYLYNjzVXG2IzkiMNE=.c8c8c32c-5959-4d74-b691-e5d7cf816685@github.com> On Tue, 25 May 2021 09:37:58 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? > > Kind regards, > Patrick src/java.base/share/classes/java/io/StreamTokenizer.java line 795: > 793: * case statements > 794: */ > 795: if (ttype < 256 && ((ctype[ttype] & CT_QUOTE) != 0)) { Maybe (since its easier to grok the yield rather than the assignment of ret in branches): String ret = switch (ttype) { case TT_EOF -> "EOF"; case TT_EOL -> "EOL"; case TT_WORD -> sval; case TT_NUMBER -> "n=" + nval; case TT_NOTHING -> "NOTHING"; default -> { /* * ttype is the first character of either a quoted string or * is an ordinary character. ttype can definitely not be less * than 0, since those are reserved values used in the previous * case statements */ if (ttype < 256 && ((ctype[ttype] & CT_QUOTE) != 0)) { yield sval; } char s[] = new char[3]; s[0] = s[2] = '''; s[1] = (char) ttype; yield new String(s); } }; return "Token[" + ret + "], line " + LINENO; ------------- PR: https://git.openjdk.java.net/jdk/pull/4182 From dfuchs at openjdk.java.net Tue May 25 13:22:03 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 25 May 2021 13:22:03 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions In-Reply-To: References: Message-ID: <_wJ--fj6N1Y1wzr5ql_b4zhbSn2r7vn8VQjeezLgnkU=.01cb0252-68cd-4099-abf6-e43659539861@github.com> On Tue, 25 May 2021 09:37:58 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? > > Kind regards, > Patrick src/java.base/share/classes/java/io/ObjectStreamField.java line 123: > 121: case 'D' -> type = Double.TYPE; > 122: case 'L', '[' -> type = Object.class; > 123: default -> throw new IllegalArgumentException("illegal signature"); Why not assign type here? type = switch(signature.charAt(0)) { case 'Z' -> Boolean.TYPE; .... ------------- PR: https://git.openjdk.java.net/jdk/pull/4182 From github.com+10835776+stsypanov at openjdk.java.net Tue May 25 13:44:14 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Tue, 25 May 2021 13:44:14 GMT Subject: RFR: 8263561: Re-examine uses of LinkedList [v4] In-Reply-To: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com> References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com> Message-ID: <8QDoLOsBNG7VYDd7ryDVkNTHt9Z-T9QeZ2ll0bWGonQ=.0335a58a-744f-4acc-a226-6c3abbc14914@github.com> > The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective. > > jdk:tier1 and jdk:tier2 are both ok ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge branch 'master' into purge-linked-list - 8263561: Use sized constructor where reasonable - 8263561: Use interface List instead of particular type where possible - 8263561: Rename requestList -> requests - 8263561: Re-examine uses of LinkedList ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2744/files - new: https://git.openjdk.java.net/jdk/pull/2744/files/40910fae..89160b3e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2744&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2744&range=02-03 Stats: 763526 lines in 11131 files changed: 166175 ins; 560683 del; 36668 mod Patch: https://git.openjdk.java.net/jdk/pull/2744.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2744/head:pull/2744 PR: https://git.openjdk.java.net/jdk/pull/2744 From pconcannon at openjdk.java.net Tue May 25 14:57:22 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Tue, 25 May 2021 14:57:22 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v2] In-Reply-To: References: Message-ID: > Hi, > > Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? > > Kind regards, > Patrick Patrick Concannon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - 8267670: Updated code to use yield - Merge remote-tracking branch 'origin/master' into JDK-8267670 - 8267670: Update java.io, java.math, and java.text to use switch expressions ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4182/files - new: https://git.openjdk.java.net/jdk/pull/4182/files/b98e47db..adc8af41 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4182&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4182&range=00-01 Stats: 143 lines in 16 files changed: 28 ins; 56 del; 59 mod Patch: https://git.openjdk.java.net/jdk/pull/4182.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4182/head:pull/4182 PR: https://git.openjdk.java.net/jdk/pull/4182 From pconcannon at openjdk.java.net Tue May 25 14:57:24 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Tue, 25 May 2021 14:57:24 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v2] In-Reply-To: <3RO89K_OHLuQJPiDTPNMTppqvW2W_U1OeQWEwJvn56U=.c3331ce0-4617-40f9-b542-adeaf9c007b6@github.com> References: <3RO89K_OHLuQJPiDTPNMTppqvW2W_U1OeQWEwJvn56U=.c3331ce0-4617-40f9-b542-adeaf9c007b6@github.com> Message-ID: On Tue, 25 May 2021 12:31:38 GMT, Chris Hegarty wrote: >> Patrick Concannon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - 8267670: Updated code to use yield >> - Merge remote-tracking branch 'origin/master' into JDK-8267670 >> - 8267670: Update java.io, java.math, and java.text to use switch expressions > > src/java.base/share/classes/java/io/ObjectInputStream.java line 1877: > >> 1875: descriptor.checkInitialized(); >> 1876: } >> 1877: default -> throw new StreamCorruptedException( > > What would you think of assigning descriptor with the value returned from evaluating the switch? > > Either: > > 1) > > ObjectStreamClass descriptor = switch (tc) { > case TC_NULL -> (ObjectStreamClass) readNull(); > case TC_PROXYCLASSDESC -> readProxyDesc(unshared); > case TC_CLASSDESC -> readNonProxyDesc(unshared); > case TC_REFERENCE -> readAndCheckHandle(unshared); > default -> throw new StreamCorruptedException(String.format("invalid type code: %02X", tc)); > }; > return descriptor; > } > > , where the body of TC_REFERENCE is enclosed in readAndCheckHandle, OR > > 2) Simply > > case TC_REFERENCE -> { > var d = (ObjectStreamClass)readHandle(unshared); > // Should only reference initialized class descriptors > d.checkInitialized(); > yield d; } Code updated as suggested. See adc8af4 > src/java.base/share/classes/java/io/StreamTokenizer.java line 795: > >> 793: * case statements >> 794: */ >> 795: if (ttype < 256 && ((ctype[ttype] & CT_QUOTE) != 0)) { > > Maybe (since its easier to grok the yield rather than the assignment of ret in branches): > > String ret = switch (ttype) { > case TT_EOF -> "EOF"; > case TT_EOL -> "EOL"; > case TT_WORD -> sval; > case TT_NUMBER -> "n=" + nval; > case TT_NOTHING -> "NOTHING"; > default -> { > /* > * ttype is the first character of either a quoted string or > * is an ordinary character. ttype can definitely not be less > * than 0, since those are reserved values used in the previous > * case statements > */ > if (ttype < 256 && ((ctype[ttype] & CT_QUOTE) != 0)) { > yield sval; > } > char s[] = new char[3]; > s[0] = s[2] = '''; > s[1] = (char) ttype; > yield new String(s); > } > }; > return "Token[" + ret + "], line " + LINENO; Code updated as suggested. See adc8af4 ------------- PR: https://git.openjdk.java.net/jdk/pull/4182 From pconcannon at openjdk.java.net Tue May 25 14:57:26 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Tue, 25 May 2021 14:57:26 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v2] In-Reply-To: <_wJ--fj6N1Y1wzr5ql_b4zhbSn2r7vn8VQjeezLgnkU=.01cb0252-68cd-4099-abf6-e43659539861@github.com> References: <_wJ--fj6N1Y1wzr5ql_b4zhbSn2r7vn8VQjeezLgnkU=.01cb0252-68cd-4099-abf6-e43659539861@github.com> Message-ID: On Tue, 25 May 2021 13:16:00 GMT, Daniel Fuchs wrote: >> Patrick Concannon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - 8267670: Updated code to use yield >> - Merge remote-tracking branch 'origin/master' into JDK-8267670 >> - 8267670: Update java.io, java.math, and java.text to use switch expressions > > src/java.base/share/classes/java/io/ObjectStreamField.java line 123: > >> 121: case 'D' -> type = Double.TYPE; >> 122: case 'L', '[' -> type = Object.class; >> 123: default -> throw new IllegalArgumentException("illegal signature"); > > Why not assign type here? > > > type = switch(signature.charAt(0)) { > case 'Z' -> Boolean.TYPE; > .... Thanks for your suggestion. I've done that now. See adc8af4 ------------- PR: https://git.openjdk.java.net/jdk/pull/4182 From pconcannon at openjdk.java.net Tue May 25 14:57:28 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Tue, 25 May 2021 14:57:28 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v2] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 12:43:00 GMT, Naoto Sato wrote: >> Patrick Concannon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - 8267670: Updated code to use yield >> - Merge remote-tracking branch 'origin/master' into JDK-8267670 >> - 8267670: Update java.io, java.math, and java.text to use switch expressions > > src/java.base/share/classes/java/text/BreakIterator.java line 569: > >> 567: case SENTENCE_INDEX -> breakIteratorProvider.getSentenceInstance(locale); >> 568: default -> null; >> 569: }; > > No need to use the local variable `iterator` here. Simply return with the switch expression. Hi Naoto, thanks for spotting this. Code updated as suggested. See adc8af4 > src/java.base/share/classes/java/text/NumberFormat.java line 982: > >> 980: case COMPACTSTYLE -> provider.getCompactNumberInstance(locale, formatStyle); >> 981: default -> null; >> 982: }; > > Same as `BreakIterator`. No need for `numberFormat`. Code updated as suggested. See adc8af4 ------------- PR: https://git.openjdk.java.net/jdk/pull/4182 From chegar at openjdk.java.net Tue May 25 15:22:59 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Tue, 25 May 2021 15:22:59 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v2] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 14:57:22 GMT, Patrick Concannon wrote: >> Hi, >> >> Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? >> >> Kind regards, >> Patrick > > Patrick Concannon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - 8267670: Updated code to use yield > - Merge remote-tracking branch 'origin/master' into JDK-8267670 > - 8267670: Update java.io, java.math, and java.text to use switch expressions src/java.base/share/classes/java/io/ObjectStreamClass.java line 2172: > 2170: switch (typeCodes[i]) { > 2171: case 'L', '[' -> vals[offsets[i]] = unsafe.getReference(obj, readKeys[i]); > 2172: default -> throw new InternalError(); suggest: vals[offsets[i]] = switch (typeCodes[i]) { case 'L', '[' -> unsafe.getReference(obj, readKeys[i]); default -> throw new InternalError(); src/java.base/share/classes/java/io/StreamTokenizer.java line 787: > 785: case TT_WORD -> ret = sval; > 786: case TT_NUMBER -> ret = "n=" + nval; > 787: case TT_NOTHING -> ret = "NOTHING"; This is not correct, the assignments to ret in these case arms is redundant. ------------- PR: https://git.openjdk.java.net/jdk/pull/4182 From chegar at openjdk.java.net Tue May 25 15:26:56 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Tue, 25 May 2021 15:26:56 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v2] In-Reply-To: References: <3RO89K_OHLuQJPiDTPNMTppqvW2W_U1OeQWEwJvn56U=.c3331ce0-4617-40f9-b542-adeaf9c007b6@github.com> Message-ID: On Tue, 25 May 2021 14:53:44 GMT, Patrick Concannon wrote: >> src/java.base/share/classes/java/io/StreamTokenizer.java line 795: >> >>> 793: * case statements >>> 794: */ >>> 795: if (ttype < 256 && ((ctype[ttype] & CT_QUOTE) != 0)) { >> >> Maybe (since its easier to grok the yield rather than the assignment of ret in branches): >> >> String ret = switch (ttype) { >> case TT_EOF -> "EOF"; >> case TT_EOL -> "EOL"; >> case TT_WORD -> sval; >> case TT_NUMBER -> "n=" + nval; >> case TT_NOTHING -> "NOTHING"; >> default -> { >> /* >> * ttype is the first character of either a quoted string or >> * is an ordinary character. ttype can definitely not be less >> * than 0, since those are reserved values used in the previous >> * case statements >> */ >> if (ttype < 256 && ((ctype[ttype] & CT_QUOTE) != 0)) { >> yield sval; >> } >> char s[] = new char[3]; >> s[0] = s[2] = '''; >> s[1] = (char) ttype; >> yield new String(s); >> } >> }; >> return "Token[" + ret + "], line " + LINENO; > > Code updated as suggested. See adc8af4 The snippet above both uses yield in the default case, and also removes the assignments from the other arms. adc8af4 overlooks the redundant assignments in the non-default cases. ------------- PR: https://git.openjdk.java.net/jdk/pull/4182 From chegar at openjdk.java.net Tue May 25 15:54:57 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Tue, 25 May 2021 15:54:57 GMT Subject: RFR: 8267587: Update java.util to use enhanced switch [v5] In-Reply-To: References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> Message-ID: On Tue, 25 May 2021 11:49:18 GMT, Tagir F. Valeev wrote: >> Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc. >> >> I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement? > > Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: > > More vertical alignment src/java.base/share/classes/java/util/Calendar.java line 1507: > 1505: } > 1506: case "japanese" -> cal = new JapaneseImperialCalendar(zone, locale, true); > 1507: default -> throw new IllegalArgumentException("unknown calendar type: " + type); In this case, it would be good to yield the result of the switch expression and assign that to a local, rather than assigning in each of the case arms, e.g: final Calendar cal = switch (type) { case "gregory" -> new GregorianCalendar(zone, locale, true); case "iso8601" -> { GregorianCalendar gcal = new GregorianCalendar(zone, locale, true); // make gcal a proleptic Gregorian gcal.setGregorianChange(new Date(Long.MIN_VALUE)); // and week definition to be compatible with ISO 8601 setWeekDefinition(MONDAY, 4); yield gcal; } case "buddhist" -> { var buddhistCalendar = new BuddhistCalendar(zone, locale); buddhistCalendar.clear(); yield buddhistCalendar; } case "japanese" -> new JapaneseImperialCalendar(zone, locale, true); default -> throw new IllegalArgumentException("unknown calendar type: " + type); }; ------------- PR: https://git.openjdk.java.net/jdk/pull/4161 From briangoetz at openjdk.java.net Tue May 25 16:49:59 2021 From: briangoetz at openjdk.java.net (Brian Goetz) Date: Tue, 25 May 2021 16:49:59 GMT Subject: RFR: 8267587: Update java.util to use enhanced switch [v5] In-Reply-To: References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> Message-ID: On Tue, 25 May 2021 11:49:18 GMT, Tagir F. Valeev wrote: >> Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc. >> >> I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement? > > Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: > > More vertical alignment src/java.base/share/classes/java/util/Calendar.java line 1507: > 1505: } > 1506: case "japanese" -> cal = new JapaneseImperialCalendar(zone, locale, true); > 1507: default -> throw new IllegalArgumentException("unknown calendar type: " + type); Agree with Chris' suggestion here. ------------- PR: https://git.openjdk.java.net/jdk/pull/4161 From naoto at openjdk.java.net Tue May 25 16:53:07 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 25 May 2021 16:53:07 GMT Subject: RFR: 8187649: ArrayIndexOutOfBoundsException in java.util.JapaneseImperialCalendar Message-ID: Please review the fix. The issue was informed yesterday by @amaembo that it offends some code analysis tools. Although the fix is to change the condition error, it turned out that `JapaneseImperialCalendar.roll()` did not work for `WEEK_OF_MONTH` and `DAY_OF_MONTH`. There was an inherent issue where `GregorianCalendar` does not follow the `roll()` spec, i.e., "The MONTH must not change when the WEEK_OF_MONTH is rolled." during the Julian/Gregorian transition. JDK-6191841 seems to have tried to fix it but it was closed as `Future Project`... So I simply fixed the `roll()` issue in `JapaneseImperialCalendar` to follow the spec here, which seems to be the intent of the original author. ------------- Commit messages: - 8187649: ArrayIndexOutOfBoundsException in java.util.JapaneseImperialCalendar Changes: https://git.openjdk.java.net/jdk/pull/4191/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4191&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8187649 Stats: 46 lines in 3 files changed: 36 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/4191.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4191/head:pull/4191 PR: https://git.openjdk.java.net/jdk/pull/4191 From briangoetz at openjdk.java.net Tue May 25 16:55:06 2021 From: briangoetz at openjdk.java.net (Brian Goetz) Date: Tue, 25 May 2021 16:55:06 GMT Subject: RFR: 8267587: Update java.util to use enhanced switch [v5] In-Reply-To: References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> Message-ID: On Tue, 25 May 2021 11:49:18 GMT, Tagir F. Valeev wrote: >> Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc. >> >> I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement? > > Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: > > More vertical alignment src/java.base/share/classes/java/util/JapaneseImperialCalendar.java line 1124: > 1122: return Math.max(LEAST_MAX_VALUES[YEAR], d.getYear()); > 1123: } > 1124: } A switch with one element here is kind of weird. I would turn this into "return switch (field) { ... }", with two cases, YEAR and default. src/java.base/share/classes/java/util/JapaneseImperialCalendar.java line 1371: > 1369: } > 1370: } > 1371: } Pull value assignment out of switch? ------------- PR: https://git.openjdk.java.net/jdk/pull/4161 From darcy at openjdk.java.net Tue May 25 16:57:57 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 25 May 2021 16:57:57 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v2] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 14:57:22 GMT, Patrick Concannon wrote: >> Hi, >> >> Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? >> >> Kind regards, >> Patrick > > Patrick Concannon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - 8267670: Updated code to use yield > - Merge remote-tracking branch 'origin/master' into JDK-8267670 > - 8267670: Update java.io, java.math, and java.text to use switch expressions Changes in java.math look fine. ------------- Marked as reviewed by darcy (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4182 From pconcannon at openjdk.java.net Tue May 25 21:43:36 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Tue, 25 May 2021 21:43:36 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v3] In-Reply-To: References: Message-ID: > Hi, > > Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? > > Kind regards, > Patrick Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision: 8267670: Remove redundant code from switch ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4182/files - new: https://git.openjdk.java.net/jdk/pull/4182/files/adc8af41..e503ed26 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4182&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4182&range=01-02 Stats: 24 lines in 3 files changed: 4 ins; 3 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/4182.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4182/head:pull/4182 PR: https://git.openjdk.java.net/jdk/pull/4182 From chegar at openjdk.java.net Tue May 25 21:43:44 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Tue, 25 May 2021 21:43:44 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v3] In-Reply-To: References: Message-ID: <0gqeytkQm1L1FABLnM3XoXuT6RzChmUOFvGKzHd25cE=.c57641c6-198e-4910-ac68-3a1df3c919b2@github.com> On Tue, 25 May 2021 18:54:48 GMT, Patrick Concannon wrote: >> Hi, >> >> Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? >> >> Kind regards, >> Patrick > > Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision: > > 8267670: Remove redundant code from switch Marked as reviewed by chegar (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4182 From joehw at openjdk.java.net Tue May 25 22:34:14 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Tue, 25 May 2021 22:34:14 GMT Subject: RFR: 8187649: ArrayIndexOutOfBoundsException in java.util.JapaneseImperialCalendar In-Reply-To: References: Message-ID: On Tue, 25 May 2021 16:40:53 GMT, Naoto Sato wrote: > Please review the fix. The issue was informed yesterday by @amaembo that it offends some code analysis tools. > Although the fix is to change the condition error, it turned out that `JapaneseImperialCalendar.roll()` did not work for `WEEK_OF_MONTH` and `DAY_OF_MONTH`. There was an inherent issue where `GregorianCalendar` does not follow the `roll()` spec, i.e., "The MONTH must not change when the WEEK_OF_MONTH is rolled." during the Julian/Gregorian transition. JDK-6191841 seems to have tried to fix it but it was closed as `Future Project`... > So I simply fixed the `roll()` issue in `JapaneseImperialCalendar` to follow the spec here, which seems to be the intent of the original author. Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4191 From naoto at openjdk.java.net Wed May 26 01:20:16 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 26 May 2021 01:20:16 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v3] In-Reply-To: References: Message-ID: <7vO2Ar5e7mqC9QJ92-OsjkDHo84AXz1kHK93GfZw_lU=.1eae87c2-5032-451d-8d3d-3f7f2c0144dd@github.com> On Tue, 25 May 2021 21:43:36 GMT, Patrick Concannon wrote: >> Hi, >> >> Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? >> >> Kind regards, >> Patrick > > Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision: > > 8267670: Remove redundant code from switch Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4182 From iris at openjdk.java.net Wed May 26 02:04:12 2021 From: iris at openjdk.java.net (Iris Clark) Date: Wed, 26 May 2021 02:04:12 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v3] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 21:43:36 GMT, Patrick Concannon wrote: >> Hi, >> >> Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? >> >> Kind regards, >> Patrick > > Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision: > > 8267670: Remove redundant code from switch Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4182 From tvaleev at openjdk.java.net Wed May 26 02:22:43 2021 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Wed, 26 May 2021 02:22:43 GMT Subject: RFR: 8267587: Update java.util to use enhanced switch [v5] In-Reply-To: References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> Message-ID: On Tue, 25 May 2021 15:51:38 GMT, Chris Hegarty wrote: >> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: >> >> More vertical alignment > > src/java.base/share/classes/java/util/Calendar.java line 1507: > >> 1505: } >> 1506: case "japanese" -> cal = new JapaneseImperialCalendar(zone, locale, true); >> 1507: default -> throw new IllegalArgumentException("unknown calendar type: " + type); > > In this case, it would be good to yield the result of the switch expression and assign that to a local, rather than assigning in each of the case arms, e.g: > > final Calendar cal = switch (type) { > case "gregory" -> new GregorianCalendar(zone, locale, true); > case "iso8601" -> { > GregorianCalendar gcal = new GregorianCalendar(zone, locale, true); > // make gcal a proleptic Gregorian > gcal.setGregorianChange(new Date(Long.MIN_VALUE)); > // and week definition to be compatible with ISO 8601 > setWeekDefinition(MONDAY, 4); > yield gcal; > } > case "buddhist" -> { > var buddhistCalendar = new BuddhistCalendar(zone, locale); > buddhistCalendar.clear(); > yield buddhistCalendar; > } > case "japanese" -> new JapaneseImperialCalendar(zone, locale, true); > default -> throw new IllegalArgumentException("unknown calendar type: " + type); > }; Done, thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/4161 From tvaleev at openjdk.java.net Wed May 26 02:22:42 2021 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Wed, 26 May 2021 02:22:42 GMT Subject: RFR: 8267587: Update java.util to use enhanced switch [v6] In-Reply-To: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> Message-ID: > Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc. > > I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement? Tagir F. Valeev has updated the pull request incrementally with two additional commits since the last revision: - JapaneseImperialCalendar: use switch expressions - Use yield in java.util.Calendar.Builder.build ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4161/files - new: https://git.openjdk.java.net/jdk/pull/4161/files/f4ad5f14..e8cdf10e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4161&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4161&range=04-05 Stats: 155 lines in 2 files changed: 56 ins; 61 del; 38 mod Patch: https://git.openjdk.java.net/jdk/pull/4161.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4161/head:pull/4161 PR: https://git.openjdk.java.net/jdk/pull/4161 From tvaleev at openjdk.java.net Wed May 26 02:22:45 2021 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Wed, 26 May 2021 02:22:45 GMT Subject: RFR: 8267587: Update java.util to use enhanced switch [v5] In-Reply-To: References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> Message-ID: On Tue, 25 May 2021 16:47:15 GMT, Brian Goetz wrote: >> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: >> >> More vertical alignment > > src/java.base/share/classes/java/util/Calendar.java line 1507: > >> 1505: } >> 1506: case "japanese" -> cal = new JapaneseImperialCalendar(zone, locale, true); >> 1507: default -> throw new IllegalArgumentException("unknown calendar type: " + type); > > Agree with Chris' suggestion here. Done! > src/java.base/share/classes/java/util/JapaneseImperialCalendar.java line 1124: > >> 1122: return Math.max(LEAST_MAX_VALUES[YEAR], d.getYear()); >> 1123: } >> 1124: } > > A switch with one element here is kind of weird. I would turn this into "return switch (field) { ... }", with two cases, YEAR and default. Done, also at line 1169 ------------- PR: https://git.openjdk.java.net/jdk/pull/4161 From iris at openjdk.java.net Wed May 26 02:30:13 2021 From: iris at openjdk.java.net (Iris Clark) Date: Wed, 26 May 2021 02:30:13 GMT Subject: RFR: 8267587: Update java.util to use enhanced switch [v6] In-Reply-To: References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> Message-ID: On Wed, 26 May 2021 02:22:42 GMT, Tagir F. Valeev wrote: >> Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc. >> >> I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement? > > Tagir F. Valeev has updated the pull request incrementally with two additional commits since the last revision: > > - JapaneseImperialCalendar: use switch expressions > - Use yield in java.util.Calendar.Builder.build Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4161 From tvaleev at openjdk.java.net Wed May 26 02:30:15 2021 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Wed, 26 May 2021 02:30:15 GMT Subject: RFR: 8267587: Update java.util to use enhanced switch [v6] In-Reply-To: References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> Message-ID: On Wed, 26 May 2021 02:22:42 GMT, Tagir F. Valeev wrote: >> Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc. >> >> I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement? > > Tagir F. Valeev has updated the pull request incrementally with two additional commits since the last revision: > > - JapaneseImperialCalendar: use switch expressions > - Use yield in java.util.Calendar.Builder.build src/java.base/share/classes/java/util/JapaneseImperialCalendar.java line 1316: > 1314: JapaneseImperialCalendar jc = getNormalizedCalendar(); > 1315: LocalGregorianCalendar.Date date = jc.jdate; > 1316: int normalizedYear = date.getNormalizedYear(); This variable was unused src/java.base/share/classes/java/util/JapaneseImperialCalendar.java line 1423: > 1421: case WEEK_OF_MONTH -> { > 1422: LocalGregorianCalendar.Date jd = jcal.getCalendarDate(Long.MAX_VALUE, getZone()); > 1423: if (date.getEra() == jd.getEra() && date.getYear() == jd.getYear()) { I inverted the `if` condition here, as it was negated and a much shorter branch was in `else`. ------------- PR: https://git.openjdk.java.net/jdk/pull/4161 From tvaleev at openjdk.java.net Wed May 26 02:30:16 2021 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Wed, 26 May 2021 02:30:16 GMT Subject: RFR: 8267587: Update java.util to use enhanced switch [v5] In-Reply-To: References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> Message-ID: On Tue, 25 May 2021 16:52:06 GMT, Brian Goetz wrote: >> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: >> >> More vertical alignment > > src/java.base/share/classes/java/util/JapaneseImperialCalendar.java line 1371: > >> 1369: } >> 1370: } >> 1371: } > > Pull value assignment out of switch? This is a much bigger change which is probably harder to review. I did it, please take a look. One point is whether to unwrap the final `else` after `yield`: if (...) { ... yield ... } else { // should we remove else? ... } I prefer unwrapping, as this reduces the indentation, so I did it. Please tell me if this contradicts with the preferred OpenJDK style. ------------- PR: https://git.openjdk.java.net/jdk/pull/4161 From pconcannon at openjdk.java.net Wed May 26 09:00:17 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Wed, 26 May 2021 09:00:17 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v2] In-Reply-To: References: Message-ID: <0hbVhBGdyJlPs_mHkTacFWwGyHM5JOLnDghCvXoDGdY=.f8e8e70d-3ad3-45f7-9046-21d6721c4ffd@github.com> On Tue, 25 May 2021 15:18:46 GMT, Chris Hegarty wrote: >> Patrick Concannon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - 8267670: Updated code to use yield >> - Merge remote-tracking branch 'origin/master' into JDK-8267670 >> - 8267670: Update java.io, java.math, and java.text to use switch expressions > > src/java.base/share/classes/java/io/ObjectStreamClass.java line 2172: > >> 2170: switch (typeCodes[i]) { >> 2171: case 'L', '[' -> vals[offsets[i]] = unsafe.getReference(obj, readKeys[i]); >> 2172: default -> throw new InternalError(); > > suggest: > > vals[offsets[i]] = switch (typeCodes[i]) { > case 'L', '[' -> unsafe.getReference(obj, readKeys[i]); > default -> throw new InternalError(); Comment addressed in e503ed2 > src/java.base/share/classes/java/io/StreamTokenizer.java line 787: > >> 785: case TT_WORD -> ret = sval; >> 786: case TT_NUMBER -> ret = "n=" + nval; >> 787: case TT_NOTHING -> ret = "NOTHING"; > > This is not correct, the assignments to ret in these case arms is redundant. Comment addressed in e503ed2 ------------- PR: https://git.openjdk.java.net/jdk/pull/4182 From pconcannon at openjdk.java.net Wed May 26 09:05:34 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Wed, 26 May 2021 09:05:34 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v4] In-Reply-To: References: Message-ID: > Hi, > > Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? > > Kind regards, > Patrick Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision: 8267670: Removed trailing whitespace ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4182/files - new: https://git.openjdk.java.net/jdk/pull/4182/files/e503ed26..d4a6cc44 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4182&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4182&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4182.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4182/head:pull/4182 PR: https://git.openjdk.java.net/jdk/pull/4182 From pconcannon at openjdk.java.net Wed May 26 09:39:44 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Wed, 26 May 2021 09:39:44 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v4] In-Reply-To: References: Message-ID: On Wed, 26 May 2021 09:05:34 GMT, Patrick Concannon wrote: >> Hi, >> >> Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? >> >> Kind regards, >> Patrick > > Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision: > > 8267670: Removed trailing whitespace > _Mailing list message from [Brian Goetz](mailto:brian.goetz at oracle.com) on [core-libs-dev](mailto:core-libs-dev at mail.openjdk.java.net):_ > > In the last hunk, you convert > > case Collator.IDENTICAL: toAddTo.append('='); break; > case Collator.TERTIARY: toAddTo.append(','); break; > case Collator.SECONDARY: toAddTo.append(';'); break; > case Collator.PRIMARY: toAddTo.append('<'); break; > case RESET: toAddTo.append('&'); break; > case UNSET: toAddTo.append('?'); break; > > to > > case Collator.IDENTICAL -> toAddTo.append('='); > case Collator.TERTIARY -> toAddTo.append(','); > case Collator.SECONDARY -> toAddTo.append(';'); > case Collator.PRIMARY -> toAddTo.append('<'); > case RESET -> toAddTo.append('&'); > case UNSET -> toAddTo.append('?'); > > But, you can go further, pulling the toAddTo.append() call out of the switch. This was one of the benefits we anticipated with expression switches; that it would expose more opportunities to push the conditional logic farther down towards the leaves. I suspect there are other opportunities for this in this patch too. Hi Brian, Thanks for your suggestion. I've incorporated it into the PR, and you can find it in commit e503ed2 ------------- PR: https://git.openjdk.java.net/jdk/pull/4182 From pconcannon at openjdk.java.net Wed May 26 09:39:44 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Wed, 26 May 2021 09:39:44 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v5] In-Reply-To: References: Message-ID: > Hi, > > Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? > > Kind regards, > Patrick Patrick Concannon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into JDK-8267670 - 8267670: Removed trailing whitespace - 8267670: Remove redundant code from switch - 8267670: Updated code to use yield - Merge remote-tracking branch 'origin/master' into JDK-8267670 - 8267670: Update java.io, java.math, and java.text to use switch expressions ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4182/files - new: https://git.openjdk.java.net/jdk/pull/4182/files/d4a6cc44..ad7aeacd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4182&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4182&range=03-04 Stats: 1031 lines in 36 files changed: 717 ins; 101 del; 213 mod Patch: https://git.openjdk.java.net/jdk/pull/4182.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4182/head:pull/4182 PR: https://git.openjdk.java.net/jdk/pull/4182 From dfuchs at openjdk.java.net Wed May 26 10:01:17 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 26 May 2021 10:01:17 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v5] In-Reply-To: References: Message-ID: On Wed, 26 May 2021 09:39:44 GMT, Patrick Concannon wrote: >> Hi, >> >> Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? >> >> Kind regards, >> Patrick > > Patrick Concannon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into JDK-8267670 > - 8267670: Removed trailing whitespace > - 8267670: Remove redundant code from switch > - 8267670: Updated code to use yield > - Merge remote-tracking branch 'origin/master' into JDK-8267670 > - 8267670: Update java.io, java.math, and java.text to use switch expressions Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4182 From pconcannon at openjdk.java.net Wed May 26 10:24:34 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Wed, 26 May 2021 10:24:34 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v6] In-Reply-To: References: Message-ID: > Hi, > > Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? > > Kind regards, > Patrick Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision: 8267670: Added missing brace ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4182/files - new: https://git.openjdk.java.net/jdk/pull/4182/files/ad7aeacd..a0dfbeba Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4182&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4182&range=04-05 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4182.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4182/head:pull/4182 PR: https://git.openjdk.java.net/jdk/pull/4182 From pconcannon at openjdk.java.net Wed May 26 10:30:43 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Wed, 26 May 2021 10:30:43 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v7] In-Reply-To: References: Message-ID: <5H6mlbt9InJc2lxeoRA-YxxVGa67EcT2ErCojXKj22Y=.5df1c233-91bc-4ad0-8d84-30418c9f56f3@github.com> > Hi, > > Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? > > Kind regards, > Patrick Patrick Concannon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into JDK-8267670 - 8267670: Added missing brace - Merge remote-tracking branch 'origin/master' into JDK-8267670 - 8267670: Removed trailing whitespace - 8267670: Remove redundant code from switch - 8267670: Updated code to use yield - Merge remote-tracking branch 'origin/master' into JDK-8267670 - 8267670: Update java.io, java.math, and java.text to use switch expressions ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4182/files - new: https://git.openjdk.java.net/jdk/pull/4182/files/a0dfbeba..57184fbf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4182&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4182&range=05-06 Stats: 29 lines in 1 file changed: 17 ins; 5 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/4182.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4182/head:pull/4182 PR: https://git.openjdk.java.net/jdk/pull/4182 From naoto at openjdk.java.net Wed May 26 15:56:19 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 26 May 2021 15:56:19 GMT Subject: Integrated: 8263202: Update Hebrew/Indonesian/Yiddish ISO 639 language codes to current In-Reply-To: References: Message-ID: <8xyafh6jhUyivyq8jtpLoQ4HX9YX-R0wHNZ2VpWTyxY=.1a12a544-1668-49b7-bafd-ed833a292b91@github.com> On Mon, 17 May 2021 16:55:35 GMT, Naoto Sato wrote: > Please review the changes to the subject issue. java.util.Locale class has a long-standing issue for those obsolete ISO 639 languages where its normalization ends up in the obsolete codes. This change intends to flip the normalization towards the current codes, providing a system property for compatibility behavior. ResourceBundle class is also modified to load either obsolete/current bundles. For more detail, take a look at the CSR. This pull request has now been integrated. Changeset: a4c46e1e Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/a4c46e1e4f4f2f05c8002b2af683a390fc46b424 Stats: 386 lines in 35 files changed: 240 ins; 41 del; 105 mod 8263202: Update Hebrew/Indonesian/Yiddish ISO 639 language codes to current Reviewed-by: joehw ------------- PR: https://git.openjdk.java.net/jdk/pull/4069 From rriggs at openjdk.java.net Wed May 26 18:41:05 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 26 May 2021 18:41:05 GMT Subject: RFR: 8187649: ArrayIndexOutOfBoundsException in java.util.JapaneseImperialCalendar In-Reply-To: References: Message-ID: On Tue, 25 May 2021 16:40:53 GMT, Naoto Sato wrote: > Please review the fix. The issue was informed yesterday by @amaembo that it offends some code analysis tools. > Although the fix is to change the condition error, it turned out that `JapaneseImperialCalendar.roll()` did not work for `WEEK_OF_MONTH` and `DAY_OF_MONTH`. There was an inherent issue where `GregorianCalendar` does not follow the `roll()` spec, i.e., "The MONTH must not change when the WEEK_OF_MONTH is rolled." during the Julian/Gregorian transition. JDK-6191841 seems to have tried to fix it but it was closed as `Future Project`... > So I simply fixed the `roll()` issue in `JapaneseImperialCalendar` to follow the spec here, which seems to be the intent of the original author. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4191 From naoto at openjdk.java.net Thu May 27 13:22:09 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 27 May 2021 13:22:09 GMT Subject: Integrated: 8187649: ArrayIndexOutOfBoundsException in java.util.JapaneseImperialCalendar In-Reply-To: References: Message-ID: On Tue, 25 May 2021 16:40:53 GMT, Naoto Sato wrote: > Please review the fix. The issue was informed yesterday by @amaembo that it offends some code analysis tools. > Although the fix is to change the condition error, it turned out that `JapaneseImperialCalendar.roll()` did not work for `WEEK_OF_MONTH` and `DAY_OF_MONTH`. There was an inherent issue where `GregorianCalendar` does not follow the `roll()` spec, i.e., "The MONTH must not change when the WEEK_OF_MONTH is rolled." during the Julian/Gregorian transition. JDK-6191841 seems to have tried to fix it but it was closed as `Future Project`... > So I simply fixed the `roll()` issue in `JapaneseImperialCalendar` to follow the spec here, which seems to be the intent of the original author. This pull request has now been integrated. Changeset: bea4109e Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/bea4109ef75a6536af4296db56e6ec90ab0f30fc Stats: 46 lines in 3 files changed: 36 ins; 0 del; 10 mod 8187649: ArrayIndexOutOfBoundsException in java.util.JapaneseImperialCalendar Reviewed-by: joehw, rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/4191 From dfuchs at openjdk.java.net Thu May 27 13:58:13 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 27 May 2021 13:58:13 GMT Subject: RFR: 8267587: Update java.util to use enhanced switch [v6] In-Reply-To: References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> Message-ID: On Wed, 26 May 2021 02:22:42 GMT, Tagir F. Valeev wrote: >> Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc. >> >> I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement? > > Tagir F. Valeev has updated the pull request incrementally with two additional commits since the last revision: > > - JapaneseImperialCalendar: use switch expressions > - Use yield in java.util.Calendar.Builder.build Globally looks good. I haven't reviewed `src/java.base/share/classes/java/util/regex/Pattern.java` due to formatting issues. See also my other remark about `java.util.concurrent`. src/java.base/share/classes/java/util/concurrent/FutureTask.java line 495: > 493: * @return a string representation of this FutureTask > 494: */ > 495: public String toString() { Classes in java.util.concurrent are handled upstream. It would probably be better to leave them out of this patch. Or synchronize with @DougLea to see how to bring these changes in the upstream repo. ------------- PR: https://git.openjdk.java.net/jdk/pull/4161 From pconcannon at openjdk.java.net Thu May 27 15:33:36 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Thu, 27 May 2021 15:33:36 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v8] In-Reply-To: References: Message-ID: > Hi, > > Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? > > Kind regards, > Patrick Patrick Concannon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into JDK-8267670 - Merge remote-tracking branch 'origin/master' into JDK-8267670 - 8267670: Added missing brace - Merge remote-tracking branch 'origin/master' into JDK-8267670 - 8267670: Removed trailing whitespace - 8267670: Remove redundant code from switch - 8267670: Updated code to use yield - Merge remote-tracking branch 'origin/master' into JDK-8267670 - 8267670: Update java.io, java.math, and java.text to use switch expressions ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4182/files - new: https://git.openjdk.java.net/jdk/pull/4182/files/57184fbf..933e59e9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4182&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4182&range=06-07 Stats: 29913 lines in 434 files changed: 3355 ins; 25561 del; 997 mod Patch: https://git.openjdk.java.net/jdk/pull/4182.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4182/head:pull/4182 PR: https://git.openjdk.java.net/jdk/pull/4182 From lancea at openjdk.java.net Thu May 27 15:47:12 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 27 May 2021 15:47:12 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v8] In-Reply-To: References: Message-ID: On Thu, 27 May 2021 15:33:36 GMT, Patrick Concannon wrote: >> Hi, >> >> Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? >> >> Kind regards, >> Patrick > > Patrick Concannon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into JDK-8267670 > - Merge remote-tracking branch 'origin/master' into JDK-8267670 > - 8267670: Added missing brace > - Merge remote-tracking branch 'origin/master' into JDK-8267670 > - 8267670: Removed trailing whitespace > - 8267670: Remove redundant code from switch > - 8267670: Updated code to use yield > - Merge remote-tracking branch 'origin/master' into JDK-8267670 > - 8267670: Update java.io, java.math, and java.text to use switch expressions Looks good Patrick ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4182 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 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 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 tvaleev at openjdk.java.net Mon May 31 03:44:32 2021 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Mon, 31 May 2021 03:44:32 GMT Subject: RFR: 8267587: Update java.util to use enhanced switch [v6] In-Reply-To: References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> Message-ID: <9TPuteZ19ff8QThVw9ABT1rkUXDBscW6RYLC8whOwUE=.d179dd55-5d88-4946-8088-cf34aa4ed241@github.com> On Thu, 27 May 2021 13:47:16 GMT, Daniel Fuchs wrote: >> Tagir F. Valeev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. > > src/java.base/share/classes/java/util/concurrent/FutureTask.java line 495: > >> 493: * @return a string representation of this FutureTask >> 494: */ >> 495: public String toString() { > > Classes in java.util.concurrent are handled upstream. It would probably be better to leave them out of this patch. Or synchronize with @DougLea to see how to bring these changes in the upstream repo. I rolled back changes in java.util.concurrent. Also, rebased the branch due to conflicts in JapaneseImperialCalendar.java ------------- PR: https://git.openjdk.java.net/jdk/pull/4161 From tvaleev at openjdk.java.net Mon May 31 03:44:31 2021 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Mon, 31 May 2021 03:44:31 GMT Subject: RFR: 8267587: Update java.util to use enhanced switch [v7] In-Reply-To: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> Message-ID: > Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc. > > I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement? Tagir F. Valeev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - Rollback changes in j.u.concurrent (including formatting) - Rollback changes in j.u.concurrent - JapaneseImperialCalendar: use switch expressions - Use yield in java.util.Calendar.Builder.build - More vertical alignment - Vertical alignment for single-line switch rules - Indent some lines to make GitHub diff happier - Unindent switch cases to simplify the review - 8267587: Update java.util to use enhanced switch ------------- Changes: https://git.openjdk.java.net/jdk/pull/4161/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4161&range=06 Stats: 884 lines in 15 files changed: 108 ins; 328 del; 448 mod Patch: https://git.openjdk.java.net/jdk/pull/4161.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4161/head:pull/4161 PR: https://git.openjdk.java.net/jdk/pull/4161 From tvaleev at openjdk.java.net Mon May 31 08:52:23 2021 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Mon, 31 May 2021 08:52:23 GMT Subject: Integrated: 8267587: Update java.util to use enhanced switch In-Reply-To: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> Message-ID: On Mon, 24 May 2021 04:20:23 GMT, Tagir F. Valeev wrote: > Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc. > > I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement? This pull request has now been integrated. Changeset: ab5a7ff2 Author: Tagir F. Valeev URL: https://git.openjdk.java.net/jdk/commit/ab5a7ff2304dd4cb069ae2bbd6fdd99b3de7a6a3 Stats: 884 lines in 15 files changed: 108 ins; 328 del; 448 mod 8267587: Update java.util to use enhanced switch Reviewed-by: iris ------------- PR: https://git.openjdk.java.net/jdk/pull/4161 From chegar at openjdk.java.net Mon May 31 14:10:57 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Mon, 31 May 2021 14:10:57 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v9] In-Reply-To: <9qJLk6We2yEGQiMS0y-A8ggivVfCwcwrD7YP3IVC7qw=.017684f1-3e5f-4ae9-ba1e-c13b62127698@github.com> References: <9qJLk6We2yEGQiMS0y-A8ggivVfCwcwrD7YP3IVC7qw=.017684f1-3e5f-4ae9-ba1e-c13b62127698@github.com> Message-ID: On Mon, 31 May 2021 14:07:54 GMT, Patrick Concannon wrote: >> Hi, >> >> Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? >> >> Kind regards, >> Patrick > > Patrick Concannon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into JDK-8267670 > - Merge remote-tracking branch 'origin/master' into JDK-8267670 > - Merge remote-tracking branch 'origin/master' into JDK-8267670 > - 8267670: Added missing brace > - Merge remote-tracking branch 'origin/master' into JDK-8267670 > - 8267670: Removed trailing whitespace > - 8267670: Remove redundant code from switch > - 8267670: Updated code to use yield > - Merge remote-tracking branch 'origin/master' into JDK-8267670 > - 8267670: Update java.io, java.math, and java.text to use switch expressions Marked as reviewed by chegar (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4182 From pconcannon at openjdk.java.net Mon May 31 14:10:50 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Mon, 31 May 2021 14:10:50 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v9] In-Reply-To: References: Message-ID: <9qJLk6We2yEGQiMS0y-A8ggivVfCwcwrD7YP3IVC7qw=.017684f1-3e5f-4ae9-ba1e-c13b62127698@github.com> > Hi, > > Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? > > Kind regards, > Patrick Patrick Concannon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into JDK-8267670 - Merge remote-tracking branch 'origin/master' into JDK-8267670 - Merge remote-tracking branch 'origin/master' into JDK-8267670 - 8267670: Added missing brace - Merge remote-tracking branch 'origin/master' into JDK-8267670 - 8267670: Removed trailing whitespace - 8267670: Remove redundant code from switch - 8267670: Updated code to use yield - Merge remote-tracking branch 'origin/master' into JDK-8267670 - 8267670: Update java.io, java.math, and java.text to use switch expressions ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4182/files - new: https://git.openjdk.java.net/jdk/pull/4182/files/933e59e9..44886603 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4182&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4182&range=07-08 Stats: 6066 lines in 412 files changed: 3749 ins; 1268 del; 1049 mod Patch: https://git.openjdk.java.net/jdk/pull/4182.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4182/head:pull/4182 PR: https://git.openjdk.java.net/jdk/pull/4182 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 From iris at openjdk.java.net Mon May 31 18:50:32 2021 From: iris at openjdk.java.net (Iris Clark) Date: Mon, 31 May 2021 18:50:32 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v9] In-Reply-To: <9qJLk6We2yEGQiMS0y-A8ggivVfCwcwrD7YP3IVC7qw=.017684f1-3e5f-4ae9-ba1e-c13b62127698@github.com> References: <9qJLk6We2yEGQiMS0y-A8ggivVfCwcwrD7YP3IVC7qw=.017684f1-3e5f-4ae9-ba1e-c13b62127698@github.com> Message-ID: On Mon, 31 May 2021 14:10:50 GMT, Patrick Concannon wrote: >> Hi, >> >> Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? >> >> Kind regards, >> Patrick > > Patrick Concannon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into JDK-8267670 > - Merge remote-tracking branch 'origin/master' into JDK-8267670 > - Merge remote-tracking branch 'origin/master' into JDK-8267670 > - 8267670: Added missing brace > - Merge remote-tracking branch 'origin/master' into JDK-8267670 > - 8267670: Removed trailing whitespace > - 8267670: Remove redundant code from switch > - 8267670: Updated code to use yield > - Merge remote-tracking branch 'origin/master' into JDK-8267670 > - 8267670: Update java.io, java.math, and java.text to use switch expressions Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4182