How does Quarkus support GraalVM native image compilation?

Quarkus supports native compilation by handing GraalVM's native-image tool an already fully-augmented application — one where CDI beans are wired, reflection needs are known, and resources are identified — rather than expecting GraalVM to statically analyze a completely generic, unprocessed Java application from scratch.

./mvnw package -Dnative
# or, building inside a container to match the target OS
./mvnw package -Dnative -Dquarkus.native.container-build=true

During the build-time augmentation phase, each extension's build steps register the specific classes, methods, and resources that GraalVM's static analysis wouldn't otherwise discover on its own — things reached only through reflection, dynamic proxies, or classpath resource loading — using dedicated BuildItems that ultimately configure GraalVM's reflection and resource configuration files automatically.

This is precisely why plain, un-instrumented Java applications are notoriously hard to get working correctly under GraalVM native-image on the first try, while properly-built Quarkus extensions "just work": the extension authors have already done the registration work that a native-image build would otherwise require a developer to hand-configure through trial and error.