Discover tests with ClassLoader other than ImageClassLoader

[ziyilin]

JUnitPlatformFeature discovers tests before analysis. The discovery process will initialize some of the test classes. As they are loaded by the ImageClassloader, the initialization will cause eager class initialization error during native image building time.

This PR uses a different classloader than the ImageClassLoader in the JUnitPlatformFeature to make sure the test class initialization at discovery time won't affect the native image class initialization policy.

==updated July 7th 2023 ==
This PR launches a separated Java process to run the test discovery if -DisolateTestDiscovery=true is set (it is set by default), and goes to the original way otherwise. The reason is the initialization of test class may initialize some JDK classes that are loaded by null classloader. In this case, classloader isolation is not sufficient.

The attached demo shows the issue.
The GraalVM version is java11-22.3.1.
Simply unzip the file and run mvn -Pnative test and mvn -Pnative test -DisolateTestDiscovery=false to see the difference.

native-build-tool-demo.zip

[melix]

I am not sure this change is safe. Probably @sbrannen has more expertise than I do on this particular aspect. I'm in particular wondering about the use of the context classloader.

[ziyilin]

Just found this commit is not enough to isolate more complicated class initializations during tests discovery. SubstrateVM's pointsto analysis scans constants and adds them into native image regardless how it is loaded. If such a constant's class should not be initialized at build time, but is initialized during test discovery. The build of native test will never succeed.
I'm trying to separate the tests discovery to run in another JVM, and return a file containing discovered test classes. In this case, code will be simpler and there is no need to set context classloader anymore.

I'm in particular wondering about the use of the context classloader.

For your question. SubstrateVM sets the context classloader to ImageClassloader which loads all classes that will be compiled into the native image. The initialization status of these classes is checked at building time. The junit platform uses the context classloader to load the tests. So I changed the context classloader to avoid loading and potential initialization of test classes.

[melix]

We're going to have to revert this PR as it breaks builds with build time initialization happening with JUnit classes.

[ziyilin]

@melix Can you provide a test case？

[melix]

You simply have to run ./gradlew :native-gradle-plugin:funTest and every single test which uses nativeTest is going to fail.