Dependency Injection

1· Concept & Definition

Dependency injection (DI) is a technique in which an object receives its dependencies from an external party instead of creating or looking them up itself. The dependencies can be passed through the constructor, set into fields, or supplied through methods. A DI container performs resolution: it determines which implementation satisfies each dependency and injects it.

2· Why It Matters

• It is the mechanism that turns loose coupling into working code.
• Injection style affects immutability, testability and clarity of dependencies.
• Resolution rules determine whether an application starts at all.

Dependency injection is where the abstract goal of depending on interfaces becomes concrete: something has to create the implementation and hand it over, and in Jakarta EE that is the CDI container. The injection style then decides how honest a class is about its needs. A constructor with four parameters shows a reviewer the collaborators at a glance; four private annotated fields hide them. Resolution matters because CDI checks every injection point when the application deploys, so a missing or ambiguous bean stops start-up instead of failing on the first request that happens to need it. That fail-fast behaviour is one of the main advantages of container-based injection over manual lookups.

3· How It Works

Constructor

Dependencies are parameters of the constructor, annotated with @Inject in Jakarta EE (only one constructor may carry it). Fields can be final, the object is fully initialised after construction, and dependencies are visible in the signature. It is the recommended default.

Field

@Inject on a (non-final) field: the container sets it via reflection after construction. It is concise but hides dependencies, prevents immutability and makes unit tests depend on reflection or a container. It remains common in Jakarta EE code and is acceptable in framework-managed classes such as Faces backing beans.

Method

@Inject on a method (an initializer method in CDI terms, often a setter): the container calls it after field injection with resolved arguments. It suits optional dependencies, cyclic breaking in legacy code, or cases where several dependencies must be processed together.

Resolution

Resolution selects the bean for each injection point by comparing the required type and qualifiers with the available beans, then applying alternative selection. In Jakarta CDI this happens at deployment: unsatisfied or ambiguous dependencies are detected before the application serves requests (details in Chapter 5).

Resolution rests on bean discovery. With the default annotated discovery mode the container scans each archive for classes carrying a bean-defining annotation, such as @ApplicationScoped, @RequestScoped or @Dependent; with a beans.xml in all mode it treats every eligible class as a bean. For each bean it records its bean types, meaning the classes and interfaces it can be injected as, and its qualifiers, adding @Default when none is declared. For each injection point it then keeps only the enabled beans whose type is assignable and whose qualifiers match, and if several remain, the selected alternative with the highest priority wins. Exactly one bean must be left.

Implementations of CDI Lite, such as Quarkus ArC, perform the same analysis at build time, so wiring errors appear before the application is even packaged, and no reflection or classpath scanning is needed at start-up.

4· Java / Jakarta EE Code Examples

@ApplicationScoped
public class OrderService {
    private final OrderRepository repo;
    private final PaymentGateway payments;
 
    // constructor injection
    @Inject
    public OrderService(OrderRepository repo, PaymentGateway payments) {
        this.repo = repo;
        this.payments = payments;
    }
 
    // for proxying (normal scope)
    protected OrderService() { this(null, null); }
}

@Named @ViewScoped
public class CheckoutView implements Serializable {
    @Inject CartService cart;                                  // field injection
 
    private AuditLog audit;
    // method (initializer) injection
    @Inject void setAudit(AuditLog audit) { this.audit = audit; }
}

// Optional or multiple dependencies: programmatic lookup
@Inject Instance<DiscountRule> rules;          // zero..n implementations
public BigDecimal discount(Order o) {
    return rules.stream().map(r -> r.apply(o)).reduce(BigDecimal.ZERO, BigDecimal::add);
}

When two beans implement the same type, a qualifier states which one an injection point wants. A bean that declares a qualifier no longer has @Default, so unqualified injection points still resolve to the standard implementation.

@Qualifier
@Retention(RUNTIME)
@Target({FIELD, PARAMETER, METHOD, TYPE})
public @interface Express {}

@ApplicationScoped
public class StandardShipping implements ShippingQuote { /* ... */ }

@Express @ApplicationScoped
public class ExpressShipping implements ShippingQuote { /* ... */ }

@ApplicationScoped
public class QuoteService {
    private final ShippingQuote standard;
    private final ShippingQuote express;

    @Inject
    public QuoteService(ShippingQuote standard,          // @Default bean
                        @Express ShippingQuote express) {
        this.standard = standard;
        this.express = express;
    }

    protected QuoteService() { this(null, null); }       // client proxy
}

Constructor injection also keeps unit tests free of the container: the test simply calls the constructor with in-memory fakes or mocks.

// No container, no reflection: the constructor is the wiring
@Test
void placesOrderAndChargesCard() {
    var repo = new InMemoryOrderRepository();
    var payments = mock(PaymentGateway.class);
    var service = new OrderService(repo, payments);

    service.place(new NewOrder("A-1", new BigDecimal("20.00")));

    verify(payments).charge(new BigDecimal("20.00"));
    assertEquals(1, repo.count());
}

5· Configuration, Defaults & Diagnostics

6· Production Usage Patterns

• Constructor injection for services; field injection tolerated in UI/backing beans.
• Instance<T> for plugin-style collections of strategies.
• Startup failures on resolution errors treated as build failures (container tests in CI).

In larger code bases teams usually add two safeguards. First, a container start-up test in CI, using Weld JUnit, Arquillian or the framework's own test support, boots the real bean graph so that resolution errors fail the build rather than a deployment. Second, an ArchUnit or static-analysis rule flags field injection in service packages and constructors that grow beyond five or six parameters, which usually means a class has too many responsibilities. Plugin-style designs, such as a set of pricing or validation rules, use Instance<T> so that new behaviour is added by deploying a new bean rather than by editing a switch statement.

7· Common Pitfalls & Misconceptions

• Mixing styles arbitrarily in one code base.
• Using field injection then calling new in tests — NullPointerExceptions.
• Constructors with many parameters hidden by switching to field injection.
• Using Instance.get() for @Dependent beans without destroy() — leaks.

8· Best Practices

• Default to constructor injection; keep constructors small.
• Inject interfaces, not implementations.
• Use qualifiers rather than names for disambiguation.
• Verify wiring with container-based tests.

9· Architect's Perspective & Trade-offs

10· Interview Q&A