ClassNotFoundException in Native Mode: Quarkus GraalVM Reachability Metadata Boundaries

Quarkus uses build-time augmentation to reduce runtime memory footprint and startup time, but native compilation relies on static analysis that often fails when libraries use reflection or dynamic proxies. During the build phase, Quarkus automatically integrates the GraalVM reachability metadata repository to inform the native-image tool about necessary reflection targets. Despite this integration, applications depending on third-party libraries that load classpath resources via ClassLoader can still encounter ClassNotFoundException or NoSuchMethodException in native mode while succeeding in JVM mode.

The unresolved behavior concerns the exact boundary between automatic metadata resolution and explicit configuration. Not all reflection-heavy libraries are covered by the shared metadata repository, and some require manual @RegisterForReflection annotations. Determining which libraries fall into this gap remains unclear without inspecting native-image build logs or testing each dependency individually.

Version assumptions: Quarkus 3.x with GraalVM for JDK 21.

1. Which specific classpath resource resolution patterns via ClassLoader are known to evade automatic GraalVM reachability metadata integration in Quarkus native builds?

2. Is there a deterministic method to identify whether a third-party library requires explicit @RegisterForReflection before encountering ClassNotFoundException or NoSuchMethodException in native mode?

3. How does Quarkus 3.x prioritize between the GraalVM reachability metadata repository and application-level reflection configuration when both define overlapping reflection targets?