Quarkus somehow instructs native-image to initialize as many classes at build-time as possible (see https://quarkus.io/guides/writing-native-applications-tips#delay-class-init-in-your-app), which is not the default for native-image (see https://www.graalvm.org/latest/reference-manual/native-image/basics/#build-time-vs-run-time, https://www.graalvm.org/latest/reference-manual/native-image/optimizations-and-performance/ClassInitialization/#build-time-initialization, https://github.com/oracle/graal/pull/4684).

Because of the aforementioned Quarkus behavior, we added native-image.properties to some of our JARs, and excluded via --initialize-at-run-time some of our classes from being initialized at build-time. But since with GraalVM native-image they are not initialized at build time anyway (see graalvm-native-image-app/build/native/nativeCompile/reports/class_initialization_report_....csv generated when graalvm-native-image-app is built), we are not testing those native-image.properties.

I failed to just pass --initialize-at-build-time=org.bson,com.mongodb to native-image, because it transitively requires build-time initialization of such classes as com.sun.jna.Platform, ch.qos.logback.classic.Logger, and causes a build failure. The latter is weird as it contradicts the "simulated" initialization behavior introduced by https://github.com/oracle/graal/pull/4684.

I also failed to pass -H:+AllowDeprecatedInitializeAllClassesAtBuildTime --initialize-at-build-time to native-image. This is supposed to initialize as many classes as possible at build-time. Maybe that is how Quarkus achieves its behavior.

If we succeed with this ticket, we should also see if we can somehow automatically test our native-image.properties. Currently, there are no tests that fail if classes specified there in --initialize-at-run-time= are not initialized at run-time.