© Excellent backgrounds/Shutterstock.com
Kolumne: EnterpriseTales

Version 2.0 der CDI Specification auch in Java SE nutzbar


von Lars Röwekamp und Arne Limburg

Bisher ist CDI ein Komponentenframework, das Dependency Injection zur Verfügung stellt, allerdings nur für Java-EE-Anwendungen. Die aktuell gültige Version ist das Maintenance-Release 1.2. Wie wir bereits in der letzten Kolumne berichteten, hat die Spezifizierung von CDI 2.0 aber schon begonnen. Und sie bringt ein durchaus interessantes Feature, mit dem es möglich sein wird, CDI auch außerhalb eines Java-EE-Containers standardisiert zu benutzen. CDI soll in Java SE nutzbar werden. Wir werden in dieser Kolumne vorstellen, wie das API aussehen könnte und was noch fehlt.

Möchte man in einem Java-EE-Container Dependency Injection verwenden, so kann man dies bereits seit Java EE 5 out of the box. Dependency Injection war damals allerdings noch frameworkspezifisch. So gibt es spezielle Annotations, um Dependency Injection in EJB zu verwenden (@Resource und @EJB) und andere, um Dependency Injection in JSF zu erhalten (@ ManagedProperty). Erst seit Java EE 6 gibt es mit CDI einen einheitlichen Dependency-Injection-Standard über alle Schichten und Frameworks hinweg. Jedoch ist CDI bisher nur in Java EE verfügbar. Sobald man sich in einem reinen Servlet-Container oder gar einer Swing- oder JavaFX-Anwendung befindet, muss man entweder auf CDI verzichten oder auf implementierungsspezifische APIs zurückgreifen. Das soll sich mit CDI 2.0 ändern.

Dependency Injection in Java SE

Das erste große Dependency-Injection-Framework in Java, das Spring Framework [1], hatte sich ja bereits zum Ziel gesetzt, keinen schwergewichtigen Container zu benötigen. Es lief seit dem ersten Tag in Java SE. So war es folgerichtig, dass auch der erste Dependency-Injection-Standard JSR-330 (@Inject [2]) als Zielplattform Java SE hat. Gleiches gilt für die zugehörige Referenzimplementierung, Google Guice [3].

CDI basiert zwar auf @Inject, hatte bisher aber immer Java EE als Zielplattform. Unabhängig davon haben die CDI-Implementierungen aber auch immer die Möglichkeit, in Java SE zu laufen (Weld SE [4] und OpenWebBeans [5]), dann aber mit einem implementierungsspezifischen API.

Eines haben aber alle hier vorgestellten Frameworks gemeinsam: Es gibt bisher keinen standardisierten Weg, sie zu booten. Möchte man also eine CDI-Anwendung starten, muss man auf implementierungsspezifische APIs zurückgreifen. Ein wenig Abhilfe schafft da das Framework DeltaSpike mit CdiCtrl [6]. Hiermit ist es zumindest möglich, Weld und OpenWebBeans mit einem gemeinsamen API zu start...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang