CDI — Dependency Injection in Java EE

CDI (Contexts and Dependency Injection) ist das Standard-DI-Framework in Java EE. Seit Version 6 ist es Teil der Spezifikation und bietet endlich das, was Spring seit Jahren hat — typsichere Dependency Injection mit Annotationen.

CDI-Grundlagen¶

@Inject statt new. Der Container verwaltet den Objektlebenszyklus und löst Abhängigkeiten automatisch auf. Keine XML-Konfiguration — CDI verwendet Annotationen und Konventionen. Jede Klasse mit einer beans.xml in META-INF/WEB-INF ist ein CDI Bean.

Scopes¶

@RequestScoped — neues Objekt pro HTTP-Request. @SessionScoped — pro HTTP-Session. @ApplicationScoped — Singleton. @ConversationScoped — explizit verwalteter Scope über mehrere Requests hinweg. @Dependent — Standard, neues Objekt an jedem Injektionspunkt. Die Wahl des richtigen Scopes ist entscheidend für korrektes Verhalten und Performance.

Producers¶

@Produces-Methoden erzeugen Objekte, die der CDI-Container nicht automatisch erstellen kann (EntityManager, Konfigurationswerte, externe Ressourcen). Eine Alternative zum Factory Pattern — sauberer und deklarativer.

Interceptors und Decorators¶

Interceptors für Querschnittsbelange: @Interceptor mit @AroundInvoke für Logging, Security, Caching. Der @Transactional-Interceptor ersetzt EJB-Transaktionen. Decorators zur Erweiterung der Business-Logik ohne Änderung des Originals.

CDI vs. Spring DI¶

CDI: Standard, Teil von Java EE, typsichere Qualifikatoren. Spring: älter, größeres Ökosystem, funktioniert auch ohne App-Server. Für Java-EE-Projekte: CDI. Für Spring-Projekte: Spring DI. Mischen Sie nicht beides in derselben Anwendung.

Fazit¶

CDI ist ein ausgereiftes DI-Framework. Für Java-EE-Projekte ist es die bevorzugte Wahl — standardisiert, typsicher und mit hervorragender Integration mit EJB und JPA. Spring DI bleibt die bessere Wahl außerhalb des Java-EE-Containers.