Explain the internal working of Micronaut's compile-time dependency injection?

Micronaut's DI pipeline runs almost entirely during the Java, Kotlin, or Groovy compilation step, using the standard annotation processing API.

Concretely: the processor visits every class carrying a DI annotation and builds an internal model describing its constructor parameters, injected fields or methods, applicable qualifiers like @Named, and declared scope. From that model it emits a companion class, typically suffixed $Definition, containing the literal Java code needed to instantiate the bean and satisfy its dependencies, effectively what a human would write by hand if wiring the object graph manually.

It also emits a small service-loader-style index file so the runtime doesn't need to scan the JAR for these generated classes; it just reads the index. At startup, ApplicationContext.run() loads this index, resolves scope and ordering while respecting @Requires conditions and bean replacement, and calls into the generated definition classes to construct singletons or register factories for other scopes.

Because the "reflection-like" logic is really just generated bytecode, tools like GraalVM's static analyzer see normal method calls end to end, which is exactly why this design underpins Micronaut's native image compatibility as well as its startup speed.