Explain the internal working of Quarkus's build-time class initialization?

Quarkus and GraalVM distinguish between classes initialized at build time (their static initializers run once during the native-image build, and the resulting state is baked directly into the binary) and classes initialized at runtime (static initializers run fresh each time the application process starts), and getting this classification right matters for both correctness and performance.

By default, most application and framework classes are build-time initialized for maximum startup benefit, since baking already-initialized state into the binary avoids repeating that work on every process launch; but this becomes incorrect for classes whose state legitimately needs to differ per environment or per run — a class holding a random seed, a class that opens a file handle, or one that reads an environment variable that should reflect the actual runtime environment, not whatever was present at build time.

Quarkus and its extensions mark such classes for runtime initialization explicitly (via GraalVM's --initialize-at-run-time configuration, often applied automatically by an extension's build steps), and a common cause of subtle native-image bugs — like a "random" value that's identical on every single process restart — traces directly back to a class that should have been runtime-initialized but was build-time-initialized instead.