On Tue, 18 May 2021 11:12:00 GMT, Daniel Fuchs <dfu...@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
