`quarkus-hibernate-validator` brings a dependency that is not supported in native mode

Describe the bug

Quarkus version: Upstream / 999-SNAPSHOT

quarkus-hibernate-validator brings javax/ws/rs/ext/ExceptionMapper that throw a not found exception in native mode

Error trace:

Fatal error:java.lang.UnsupportedOperationException: Encountered an error while processing annotated types for type: io.quarkus.hibernate.validator.runtime.jaxrs.ResteasyReactiveViolationExceptionMapper$ViolationReport$Violation, executable: getField. To avoid the issue at build time, use --allow-incomplete-classpath. The error is then reported at runtime when these annotated types are first accessed.
        at com.oracle.svm.reflect.target.Target_java_lang_reflect_Executable$AnnotatedTypeEncoder.encodeAnnotationTypes(Target_java_lang_reflect_Executable.java:304)
        at com.oracle.svm.reflect.target.Target_java_lang_reflect_Executable$AnnotatedReceiverTypeComputer.compute(Target_java_lang_reflect_Executable.java:259)
        at com.oracle.svm.hosted.substitute.ComputedValueField.readValue(ComputedValueField.java:277)
        at com.oracle.svm.core.meta.ReadableJavaField.readFieldValue(ReadableJavaField.java:36)
        at com.oracle.svm.hosted.ameta.AnalysisConstantReflectionProvider.readValue(AnalysisConstantReflectionProvider.java:99)
        at com.oracle.svm.hosted.ameta.AnalysisConstantReflectionProvider.readFieldValue(AnalysisConstantReflectionProvider.java:81)
        at com.oracle.graal.pointsto.ObjectScanner.scanField(ObjectScanner.java:160)
        at com.oracle.graal.pointsto.ObjectScanner.doScan(ObjectScanner.java:333)
        at com.oracle.graal.pointsto.ObjectScanner.lambda$scanConstant$6(ObjectScanner.java:259)
        at com.oracle.graal.pointsto.util.CompletionExecutor.executeCommand(CompletionExecutor.java:188)
        at com.oracle.graal.pointsto.util.CompletionExecutor.lambda$executeService$0(CompletionExecutor.java:172)
        at java.base/java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1426)
        at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
        at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
        at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
        at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
        at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
Caused by: java.lang.NoClassDefFoundError: javax/ws/rs/ext/ExceptionMapper
        at java.base/java.lang.Class.getDeclaringClass0(Native Method)
        at java.base/java.lang.Class.getEnclosingClass(Class.java:1517)
        at java.base/sun.reflect.annotation.AnnotatedTypeFactory.nestingForType(AnnotatedTypeFactory.java:96)
        at java.base/sun.reflect.annotation.TypeAnnotationParser.buildAnnotatedType(TypeAnnotationParser.java:79)
        at java.base/java.lang.reflect.Executable.getAnnotatedReceiverType(Executable.java:676)
        at com.oracle.svm.reflect.target.Target_java_lang_reflect_Executable$AnnotatedTypeEncoder.encodeAnnotationTypes(Target_java_lang_reflect_Executable.java:293)
        ... 16 more

Expected behavior

Same behavior in JVM and native mode

Actual behavior

Fails in native mode

How to Reproduce?

git clone https://github.com/quarkus-qe/beefy-scenarios.git mvn clean verify -Dnative -pl 304-quarkus-vertx-routes

Please verify that module 304-quarkus-vertx-routes is not commented in the main pom.xml

Output of uname -a or ver

No response

Output of java -version

No response

GraalVM version (if different from Java)

No response

Quarkus version or git rev

No response

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

No response

[galderz]

I had a quick look to this. I think the issue is caused by this change in GraalVM 21.3: https://github.com/oracle/graal/commit/2cc6bc5#diff-f10eb003536457468f6d38a4e567aa18095edbba25b81c5a8f4c69d1fc71f3fcR171

I’m unsure what the exact reason for those changes are, but I think what you can gather from the way the code works is that: if you register a static inner class for reflection, it now triggers class loading the class that encloses it. The enclosing class does not appear to be in use otherwise by the Quarkus app, which is why the workaround works.

I’ll ping Loic on the GraalVM slack to see if there’s something that can be improved here.

[loicottet]

@galderz The loading of the enclosing class is triggered by the computation of type annotations for Executable objects, which is performed by JDK code. From what I can see the modifications in the commit you linked did not introduce this behaviour, but modifications to our substitutions of the copying methods in ReflectAccess now probably makes the Executable.annotatedReceiverType field reachable, which triggers that computation.

I don’t see an easy way to get around this from the Native Image side, since those modifications are necessary to ensure the correctness of our reflection implementation. We are potentially looking at a way to perform those checks at runtime instead of during the build, however this would be quite an important change.