CDI in Quarkus (ArC)

Phase 3's JAX-RS resource quietly relied on something glossed over: when you wrote @Inject ProductService, somebody created the service and handed it to the resource. This phase is that somebody - Quarkus's dependency-injection container - and the one thing it does differently from every container you've used before.

It's the same CDI you already know, but the wiring is figured out while your code compiles, not when it starts. A traditional container wakes up at startup, scans your classes, reads annotations via reflection, builds the "who needs what" graph, and then serves requests. Quarkus does almost all of that at build time - the graph is baked in before the app ever runs. Same annotations, same programming model, different timing - the build-time-over-runtime idea from Phase 1, applied to DI.

📝 If you've done CDI in Jakarta EE, you already know the programming model - @Inject, @ApplicationScoped, qualifiers, producers. This phase shows Quarkus's twist on it rather than re-teaching CDI from scratch.

It's CDI, wired at build time

📝 Quarkus's DI container is ArC - a build-time implementation of CDI. No new API: the exact same jakarta.inject and jakarta.enterprise.context annotations. The difference is when the wiring happens.

import jakarta.enterprise.context.ApplicationScoped;
import java.util.*;
import java.util.concurrent.ConcurrentHashMap;

@ApplicationScoped
public class ProductService {
    private final Map<Long, Product> store = new ConcurrentHashMap<>();

    public List<Product> all()        { return List.copyOf(store.values()); }
    public Product find(long id)      { return store.get(id); }
    public void save(Product p)       { store.put(p.id(), p); }
}

What just happened: @ApplicationScoped is the standard CDI bean-defining annotation - one instance for the whole app. Identical to Jakarta EE; ArC just notices it at compile time instead of startup.

import jakarta.inject.Inject;
import jakarta.ws.rs.*;
import java.util.List;

@Path("/products")
public class ProductResource {
    @Inject
    ProductService service;

    @GET
    public List<Product> list() {
        return service.all();
    }
}

What just happened: @Inject says "container, fill this in." ArC finds the @ApplicationScoped bean and records the connection. The field isn't private - ArC's generated injection code needs to write to it directly, avoiding reflection.

💡 Field injection is compact, which is why you see it everywhere in examples. Constructor injection is still the better habit - more below.

Why build-time DI is a big deal

💡 A runtime container's startup cost is dominated by scanning the classpath and reflection to construct beans - both happen every boot. ArC does that once, at build time, and emits plain generated code that wires everything directly. At runtime there's almost nothing left to do - a big slice of why Quarkus boots in tens of milliseconds.

The deeper win is native images. GraalVM's closed-world model (Phase 9) is hostile to reflection - anything discovered dynamically at runtime is a problem. Build-time DI sidesteps that entirely, because the wiring is settled before the native compiler runs. It's a big part of how Quarkus offers full CDI and compiles to native.

⚠️ The flip side is mostly good news: errors a runtime container throws at startup (a missing dependency, an ambiguous bean), ArC often catches at compile time.

@Path("/products")
public class ProductResource {
    @Inject
    PricingEngine pricing;   // no bean of this type exists anywhere
}

[ERROR] Build step ...ArcProcessor#validate threw an exception:
jakarta.enterprise.inject.UnsatisfiedResolutionException:
Unsatisfied dependency for type com.example.PricingEngine and qualifiers [@Default]
  - java member: com.example.ProductResource#pricing
  - declared on CLASS bean [class=com.example.ProductResource]

What just happened: ArC validated the whole graph at build time and refused to build. Classic Jakarta EE throws the same standard exception, just at deploy/startup instead. (An ambiguous dependency fails the same way; the fix is the standard @Qualifier.) Shifting failures left means you find them on your machine, not in prod.

Beans & scopes

Same CDI scopes as Jakarta EE - a quick recap, not a re-teach. A scope answers: how long does a bean live, and who shares the same instance.

📝 @ApplicationScoped is the workhorse. Full detail on scopes and the proxy machinery lives in the Jakarta EE CDI phase - it applies here unchanged.

💡 A bonus from build-time analysis: Quarkus removes unused beans - since ArC sees the whole graph, it can leave out beans nothing injects, for a smaller, faster-loading app. (Mark an apparently-unused bean @Unremovable if you need to keep it - say it's only used reflectively.)

Constructor injection & the basics

Constructor injection is the better habit, for the same reasons as in Spring and Jakarta EE:

@Path("/products")
public class ProductResource {
    private final ProductService service;

    public ProductResource(ProductService service) {   // ArC passes one in
        this.service = service;
    }

    @GET
    @Path("/{id}")
    public Product byId(@PathParam("id") long id) {
        return service.find(id);
    }
}

What just happened: a single injectable constructor doesn't even need @Inject - ArC treats the sole constructor as the injection point. service can be final, the constructor is a clear list of dependencies, and you can unit-test with a plain new ProductResource(fakeService) - no container needed.

📝 Qualifiers (a custom @Qualifier to pick between beans of the same type) and producers (@Produces methods for non-bean objects) work exactly as in standard CDI - see the Jakarta EE CDI phase; ArC resolves it all at build time.

The Spring bridge (brief)

💡 Coming from Spring? The quarkus-spring-di extension lets Spring's DI annotations work directly - @Autowired, @Component, @Service, @Value - so you can lift familiar code over:

import org.springframework.stereotype.Component;
import org.springframework.beans.factory.annotation.Autowired;

@Component                       // Spring's annotation, understood by Quarkus via quarkus-spring-di
public class ProductService {
    @Autowired
    ProductRepository repository;
}

What just happened: with the extension present, ArC understands @Component/@Autowired and wires this bean as if it were CDI - still at build time. It's a compatibility bridge for migration, not the idiomatic path.

📝 Idiomatic Quarkus uses standard CDI but resolves wiring at build time for speed and native-image friendliness. Learn CDI once and you've learned the wiring model for Quarkus, Jakarta EE, and (via the bridge) much of Spring too - the only thing genuinely different is when the magic happens.

Recap

1. ArC is build-time CDI. Quarkus's DI container, ArC, implements the standard CDI spec - same @Inject, @ApplicationScoped, qualifiers, producers - but computes the wiring graph at compile time instead of at startup. No new API, just different timing.
2. Why it matters: doing scanning and reflection once at build time (not on every boot) is a big reason Quarkus starts in milliseconds, and doing DI at build time sidesteps reflection - which is what lets full CDI coexist with GraalVM native images.
3. Errors shift left. A missing or ambiguous bean that a runtime container would throw at startup, ArC often catches at build time - the build fails on your machine instead of the server failing in prod.
4. Scopes are standard CDI. @ApplicationScoped is the common Quarkus default; @RequestScoped for per-request state; @Singleton as an eager, proxy-free variant. Full detail lives in the Jakarta EE CDI phase. Bonus: ArC removes unused beans for a smaller app.
5. Prefer constructor injection (testable, final, no reflection needed); qualifiers and producers work as in standard CDI. For Spring devs, quarkus-spring-di bridges @Autowired/@Component - but idiomatic Quarkus uses CDI.

With wiring understood, the next piece slots right in: a real persistence layer. Next we give Product a database with Hibernate and Panache.

Quick check

Test yourself on the ideas that have to stick from this phase:

[
  {
    "q": "What is the key difference between Quarkus's ArC container and a traditional CDI container?",
    "choices": [
      "ArC computes the dependency-injection wiring graph at build time, not at application startup",
      "ArC uses a completely different set of annotations from standard CDI",
      "ArC only supports field injection and forbids constructor injection",
      "ArC runs the application as interpreted bytecode instead of compiled code"
    ],
    "answer": 0,
    "explain": "ArC is a build-time implementation of the standard CDI spec. The annotations (@Inject, @ApplicationScoped, etc.) are identical to Jakarta EE; what changes is that the wiring is resolved at compile time rather than at startup - which is what enables fast boot and native images."
  },
  {
    "q": "You @Inject a type that no bean satisfies. In Quarkus, when do you find out?",
    "choices": [
      "At build time - ArC validates the dependency graph and the build fails",
      "Never - Quarkus silently injects null",
      "Only in production, on the first request that uses the bean",
      "At unit-test time only, never during the build"
    ],
    "answer": 0,
    "explain": "Because ArC analyzes the whole graph at build time, an unsatisfied (or ambiguous) dependency fails the build with the standard exception - earlier than a runtime container would throw it at startup. The failure shifts left to your machine."
  },
  {
    "q": "Why does doing dependency injection at build time help Quarkus compile to a native image?",
    "choices": [
      "It avoids runtime reflection and classpath scanning, which the native closed-world model is hostile to",
      "It makes the application use less disk space at build time",
      "It converts all beans into static methods that need no instances",
      "It disables CDI entirely so there is nothing for the native compiler to analyze"
    ],
    "answer": 0,
    "explain": "GraalVM's closed-world native compilation struggles with reflection and dynamic discovery. By resolving DI at build time and generating plain wiring code, ArC removes the runtime scanning/reflection that would otherwise break native compilation - letting full CDI and native images coexist."
  }
]