Es ist relativ spannend, dass mittlerweile Dependency Injection offensichtlich in Java EE 5 eine entscheidene Rolle spielt. Davon kann man im Java EE 5 Entwurf lesen, aber auch im Common Annotations JSR. Dies ist in sofern interessant, als das diese Thema mit EJB 3 begonnen hat, in Java EE einzug zu halten. Natürlich ist dieser Ansatz von Frameworks wie zum Beispiel Spring zuerst verwendet worden. Nun könnte man denken, dass dadurch nun zwei äquivalente Ansätze entstehen. Das ist leider nicht so.
Der wesentliche Unterschied ist, dass bei Java EE 5 nur einige ausgezeichnete Klassen (z.B. Servlets oder EJBs) Ziel einer Dependency Injection sein dürfen. Damit ist Java SE komplett ausgenommen. Außerdem - und das is schlimmer - sind in einer Java EE 5 Anwendung nur einige Klassen per DI konfigurierbar, während andere es nicht sind. Bei JNDI konnte man immerhin noch überall einen entsprechenden Lookup machen. JSR 250 sagt zwar, dass auch Java SE eines Tages in dieser Beziehung standardisiert sein soll, die Frage ist aber, wann das sein soll. Recht gut gelöst ist jedoch die Integration mit JNDI - es gibt eine eindeutige Abbildung und die Konfiguration aus dem Source Code kann durch Deployment Descriptoren überschrieben werden.
Also: Alles in Butter? Meiner Meinung nach ist Spring immer noch der elegantere Ansatz: Einige einfache Prinzipien erschlagen das Problem für alle Ressourcen in Java EE oder Java SE. Außerdem ist DI in Spring Basis für viele weitere coole Sachen. Was bedeutet das? Man sollte einfach den Ansatz wählen, mit dem man seine Probleme heute effektiv lösen kann. Ohne weitere Ideologien. Und dafür ist ein Ansatz wie der JBoss Server, den man in Tests oder Java SE Anwendungen einbetten kann, viel wichtiger als diese Standards. Obwohl auch er Spring meiner Meinung nach unterlegen ist... ¶ 21:25
