Quarkus Native Compilation and Jakarta EE Integration Boundary

Quarkus Native Compilation and Jakarta EE Integration Boundary

Answer: native compilation does not, by itself, change the declared lifecycle semantics of Jakarta EE/CDI beans. In Quarkus 3.x with ArC, CDI metadata is resolved at build time, so bean scopes, injection, and @PostConstruct generally keep the same expected semantics in the GraalVM Native Image or Mandrel executable as on the JVM.

Likely explanation

The integration boundary is the closed-world native-image build, not the Jakarta EE specification. Beans referenced only through reflection, dynamic proxies, JNI, or missing configuration resources can be pruned or fail at runtime even though they work in JVM mode. @PreDestroy and finalizers are not guaranteed in native executables the same way as on the JVM; use explicit Closeable/AutoCloseable resources and Quarkus shutdown lifecycle for critical cleanup.

Configuration parameters for this case

Parameter	Purpose in native Jakarta EE build
quarkus.native.resources.includes	Retain META-INF/beans.xml, persistence.xml, and META-INF/services files in the native image.
quarkus.native.additional-build-args	Pass GraalVM reflection, JNI, or resource configuration files required by Jakarta EE adapters.
quarkus.arc.remove-unused-beans	Controls CDI bean pruning; default true can remove beans referenced only reflectively.
quarkus.native.library-path / quarkus.native.jni-paths	Locate native libraries used by Jakarta EE adapters.
quarkus.native.enable-all-security-services	Enable Jakarta Security integration in the native build.
Extension properties such as quarkus.hibernate-orm.*, quarkus.resteasy-reactive.*, and quarkus.arc.*	Continue to apply, but verify native-specific behavior for reflection-dependent paths.

Steps for this case

1. Assume Quarkus 3.x on the Jakarta EE 10/11 lineage with ArC/CDI, RESTEasy Reactive, and Hibernate ORM; pin GraalVM Native Image or Mandrel for reproducible builds.
2. Build the native artifact with ./mvnw package -Pnative or the Gradle native profile.
3. Run the produced binary and exercise CDI bean creation, injection, and destruction; compare against JVM mode.
4. Confirm META-INF/beans.xml, persistence.xml, and META-INF/services files are retained using quarkus.native.resources.includes and native-image resource inspection.
5. Log @PostConstruct and @PreDestroy invocations in JVM dev mode and in the native executable to detect lifecycle divergence.
6. If a bean fails at runtime, enable native-image exception stack traces and review missing reflection or resource registration reported by the build.

Unverified: behavior can differ between GraalVM Native Image and Mandrel, and between Quarkus versions. Test the native binary in CI before relying on it for Jakarta EE lifecycle behavior.

Missing diagnostic detail that can change the recommendation: if a specific bean is missing or not destroyed in the native binary, is it referenced only through reflection? If yes, register reflection for that bean or exclude it from pruning; otherwise adjust the native resource or shutdown lifecycle configuration.