Gradle is unable to execute some tests

[carlosame]

Gradle was executing the tests just fine until I added tests that use a SecurityManager. Now, when I attempt to run the test suite with Gradle I get the following:

$ gradle test
Starting a Gradle Daemon (subsequent builds will be faster)

> Task :echosvg-test:test

Exception: java.lang.IllegalStateException thrown from the UncaughtExceptionHandler in thread "main"

> Task :echosvg-test:test FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':echosvg-test:test'.
> Process 'Gradle Test Executor 1' finished with non-zero exit value 1
  This problem might be caused by incorrect test process configuration.
  Please refer to the test execution section in the User Manual at https://docs.gradle.org/7.0.1/userguide/java_testing.html#sec:test_execution

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 1m 13s
85 actionable tasks: 4 executed, 81 up-to-date

I tried to give full permissions to the .gradle directory in the security policies, but that does not help. And setting java.security.debug=access,failure yields nothing. Perhaps the problem is not related to security permissions at all.

Meanwhile, I successfully execute the test suite with the Eclipse IDE.

[carlosame]

For reference, the problematic tests in the echosvg-test module are:

• io/sf/carte/echosvg/bridge/*LoadTest.java.
• io/sf/carte/echosvg/bridge/*PermissionsTest.java.
• io/sf/carte/echosvg/script/rhino/RhinoTest.java.

The io/sf/carte/echosvg/apps/rasterizer/MainTest.java test also fails but it is not important.

[carlosame]

It looks like if Gradle already put a security manager which is not giving the permission to set EchoSVG's manager:

java.security.AccessControlException: access denied ("java.util.PropertyPermission" "java.security.policy" "write")
	at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
	at java.base/java.security.AccessController.checkPermission(AccessController.java:1036)
	at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:408)
	at java.base/java.lang.System.setProperty(System.java:911)
	at io.sf.carte.echosvg.util.ApplicationSecurityEnforcer.installSecurityManager(ApplicationSecurityEnforcer.java:247)
	at io.sf.carte.echosvg.util.ApplicationSecurityEnforcer.enforceSecurity(ApplicationSecurityEnforcer.java:165)
	at io.sf.carte.echosvg.test.svg.SVGOnLoadExceptionTest$1.run(SVGOnLoadExceptionTest.java:298)
	at io.sf.carte.echosvg.test.svg.SVGOnLoadExceptionTest$1.run(SVGOnLoadExceptionTest.java:295)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:554)
	at io.sf.carte.echosvg.test.svg.SVGOnLoadExceptionTest.runTest(SVGOnLoadExceptionTest.java:295)
	at io.sf.carte.echosvg.bridge.EcmaNoLoadTest.test(EcmaNoLoadTest.java:73)

See also:

• Setting Java Security Manager will make junittests run in Gradle hang gradle/gradle#3526
• https://discuss.gradle.org/t/gradle-build-process-hangs-when-system-setsecuritymanager-new-securitymanager-is-called/11670
• https://issues.gradle.org/browse/GRADLE-2170

And in Gradle's Testing in Java & JVM projects:

For example, issues may occur if a SecurityManager is modified in a test because Gradle’s internal messaging depends on reflection and socket communication, which may be disrupted if the permissions on the security manager change. In this particular case, you should restore the original SecurityManager after the test so that the gradle test worker process can continue to function.

However, the ApplicationSecurityEnforcer is written so it restores the previous security manager, but it cannot even proceed to that because the test fails due to the above exception.

[jjYBdx4IL]

This could be fixed by adding the "-scriptSecurityOff" command line option to the test executions. Apparently gradle is bit too invasive when doing tests. If I may ask: why are you converting batik to gradle? Their maven build is largely working.

[carlosame]

why are you converting batik to gradle?

That was issue #8. It was triggered by the fact that Maven is too tied to the Maven Central repository, which I do not submit my artifacts to.

It is also easier to write small tasks to, for example, generate the test scripting jar files and copy them to a certain directory. With Batik, one had to run the old script-based build to generate those jar files.

[jjYBdx4IL]

Interesting. I'm not using any artifacts outside of central. :)

[carlosame]

This could be fixed by adding the "-scriptSecurityOff" command line option to the test executions.

The -scriptSecurityOff is a command line option of the rasterizer app, but one of the things being tested there is precisely the security, so this is not a choice. And the other affected tests are not related to the rasterizer app.

[carlosame]

I'm keeping things as they are now (with those tests excluded in Gradle) and close this issue:

1. The solution seems not trivial (if possible at all).
2. It is not a critical problem.
3. This project has limited development resources, and other priorities.
4. The Security Manager is going to be deprecated with the forthcoming JDK 17, see JEP 411.