Java migration: Add -Djava.security.manager=allow if System.setSecurityManager is used

[yeikel]

Problem statement

With the deprecation of the security manager usages of System.setSecurityManager are not allowed without the -Djava.security.manager=allow property

In Java 17 it is only a warning but in Java 20(or possibly earlier), it leads to the following error :

UnsupportedOperation The Security Manager is deprecated and will be removed in a future release

Example configuration (tests)

 <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-surefire-plugin</artifactId>
                    <version>${maven-surefire-plugin.version}</version>
                    <configuration>
                        <argLine>                         
                            -Djava.security.manager=allow
                        </argLine>
                    </configuration>
                </plugin>

Any additional context

I believe that it is rare for users to call System.setSecurityManager directly. The one example I've seen so far is for projects testing System exit calls using libraries like systemlambda

import static com.github.stefanbirkner.systemlambda.SystemLambda.catchSystemExit;
        
@Test
    void test() throws Exception {
        int actualExitCode = catchSystemExit(() -> System.exit(1));
        assertThat(actualExitCode).withFailMessage("The exit code does not match").isEqualTo(1);
    }

https://bugs.openjdk.org/browse/JDK-8199704
https://bugs.openjdk.org/browse/JDK-8267184
https://openjdk.org/jeps/411
stefanbirkner/system-lambda#27

[timtebeek]

Thanks for the helpful links and examples! Do I understand correctly that you'd want to see these added to surefire and failsafe if either of the test source sets uses System.setSecurityManager, even indirectly? Sounds like a scanning recipe could achieve that, but it might be a bit of work for what I expect to be rare. Would you be willing to put the effort in?