<Sound Dev> RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal
weijun at openjdk.java.net
Tue May 18 18:42:26 UTC 2021
On Tue, 18 May 2021 17:36:55 GMT, Alan Bateman <alanb at openjdk.org> 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> T doPrivileged(PrivilegedExceptionAction<T> 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`.
More information about the sound-dev