6.0.1 breaks GraalVM native image testing with GraalVM plugin 0.11.2

[michael-simons]

The upgrade from JUnit 6.0.0 to 6.0.1 breaks our native image test setup

https://github.com/neo4j/neo4j-jdbc/actions/runs/19024418716/job/54326185115?pr=1163#step:6:505

https://github.com/neo4j/neo4j-jdbc/blob/1a70651efac291119b24a4c18d61c61060c86cd4/neo4j-jdbc-it/neo4j-jdbc-it-cp/pom.xml#L127-L152

Reproducible with this branch https://github.com/neo4j/neo4j-jdbc/tree/dependabot/maven/org.junit-junit-bom-6.0.1:

./mvnw -Dnative -pl neo4j-jdbc-it/neo4j-jdbc-it-cp -am clean verify

Results in:

Error: Classes that should be initialized at run time got initialized during image building:
 org.junit.jupiter.engine.discovery.MethodSegmentResolver was unintentionally initialized at build time. To see why org.junit.jupiter.engine.discovery.MethodSegmentResolver got initialized use --trace-class-initialization=org.junit.jupiter.engine.discovery.MethodSegmentResolver
To see how the classes got initialized, use --trace-class-initialization=org.junit.jupiter.engine.discovery.MethodSegmentResolver

Tested with

GraalVM 21 and JUnit 6.0.1 and GraalVM Maven plugin 0.11.2

Doesn't seem to happen on GraalVM 24 and 25.

As I do wanted to upgrade the pipelines to 25 anyway, it won't be a biggy for us, but it might be for others.

[marcphilipp]

Thanks for the reporting!

We have an integration test that's supposed to catch such regressions. It uses the Gradle plugin, not the Maven one but that shouldn't make a difference. 🤔

@dnestoro Do you have an idea why the test is passing?

[marcphilipp]

Workaround: Pass --initialize-at-build-time=org.junit.jupiter.engine.discovery.MethodSegmentResolver as build argument.

[Marcono1234]

Same issue here, also with the Maven plugin:
https://github.com/google/gson/actions/runs/19040079824/job/54374607162

Started occurring once Dependabot bumped junit-bom to 6.0.1 and native-maven-plugin to 0.11.2 (in a single PR).

[Marcono1234]

A general question: Are there any plans to make interaction with the GraalVM plugin less brittle?

It feels rather error-prone that the GraalVM plugin has to maintain a hardcoded list of JUnit classes, which needs to be updated often and also requires synchronizing releases (to avoid build issues similar to the one above).

[marcphilipp]

It has already been refactored to be less brittle on JDK > 21 in native-build-tools 0.11.0.

[phipag]

It seems that the same issue appears on version 5.14.1. 5.14.0 works. I am using native maven plugin version 0.11.2.

Example version bump: aws-powertools/powertools-lambda-java#2267

native test output: https://github.com/aws-powertools/powertools-lambda-java/actions/runs/19072188351/job/54477770135?pr=2267

  Error: Classes that should be initialized at run time got initialized during image building:
   org.junit.jupiter.engine.discovery.MethodSegmentResolver was unintentionally initialized at build time. To see why org.junit.jupiter.engine.discovery.MethodSegmentResolver got initialized use --trace-class-initialization=org.junit.jupiter.engine.discovery.MethodSegmentResolver
  To see how the classes got initialized, use --trace-class-initialization=org.junit.jupiter.engine.discovery.MethodSegmentResolver
  Internal exception: com.oracle.svm.core.util.UserError$UserException: Classes that should be initialized at run time got initialized during image building:
   org.junit.jupiter.engine.discovery.MethodSegmentResolver was unintentionally initialized at build time. To see why org.junit.jupiter.engine.discovery.MethodSegmentResolver got initialized use --trace-class-initialization=org.junit.jupiter.engine.discovery.MethodSegmentResolver
  To see how the classes got initialized, use --trace-class-initialization=org.junit.jupiter.engine.discovery.MethodSegmentResolver
  	at org.graalvm.nativeimage.builder/com.oracle.svm.core.util.UserError.abort(UserError.java:75)
  	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.classinitialization.ProvenSafeClassInitializationSupport.checkDelayedInitialization(ProvenSafeClassInitializationSupport.java:277)
  	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.classinitialization.ClassInitializationFeature.duringAnalysis(ClassInitializationFeature.java:219)
  	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGenerator.lambda$runPointsToAnalysis$10(NativeImageGenerator.java:788)
  	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.FeatureHandler.forEachFeature(FeatureHandler.java:90)
  	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGenerator.lambda$runPointsToAnalysis$11(NativeImageGenerator.java:788)
  	at org.graalvm.nativeimage.pointsto/com.oracle.graal.pointsto.AbstractAnalysisEngine.runAnalysis(AbstractAnalysisEngine.java:181)
  	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGenerator.runPointsToAnalysis(NativeImageGenerator.java:785)
  	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGenerator.doRun(NativeImageGenerator.java:593)
  	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGenerator.run(NativeImageGenerator.java:551)
  	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGeneratorRunner.buildImage(NativeImageGeneratorRunner.java:538)
  	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGeneratorRunner.build(NativeImageGeneratorRunner.java:727)
  	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGeneratorRunner.start(NativeImageGeneratorRunner.java:142)
  	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGeneratorRunner.main(NativeImageGeneratorRunner.java:97)