RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests calling System.setSecurityManager

[Weijun Wang]

On Tue, 18 May 2021 11:12:00 GMT, Daniel Fuchs <dfuchs at openjdk.org> 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