How does dependency injection work in Quarkus vs traditional CDI containers?

Both use the same CDI programming model on the surface, but they resolve the dependency graph at fundamentally different times, which is the root cause of most of the practical differences in behavior and performance.

A traditional CDI container (as found in a full Jakarta EE application server) discovers beans by scanning the classpath reflectively when the application starts, building the dependency graph, proxies, and interceptor chains dynamically at that moment — work that has to be repeated on every single application boot.

Quarkus's ArC container performs that same discovery and graph resolution during the build-time augmentation phase instead: it determines which beans exist, how they're wired together, and generates the necessary bytecode (including lightweight proxies) ahead of time, so what ships in the final artifact is closer to hand-written, pre-wired code than a system that has to reflectively figure things out fresh at runtime.

The observable consequences are faster startup (no runtime scanning needed), lower memory use (no classpath scanning metadata retained), and native-image compatibility (GraalVM can statically analyze the pre-resolved graph much more easily than it could a fully dynamic, reflection-driven one) — at the cost of some CDI features that fundamentally require true runtime dynamism being unsupported or restricted in ArC.