Discover tests with ClassLoader
other than ImageClassLoader
#445
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
JUnitPlatformFeature
discovers tests before analysis. The discovery process will initialize some of the test classes. As they are loaded by theImageClassloader
, the initialization will cause eager class initialization error during native image building time.This PR uses a different classloader than the
ImageClassLoader
in theJUnitPlatformFeature
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
andmvn -Pnative test -DisolateTestDiscovery=false
to see the difference.native-build-tool-demo.zip