Neues Produkt von Interface21 Wie man hier und hier nachlesen kann, hat Interface21 ein neues Produkt: Eine Unterstützung von JSR 250. Dabei geht es um einige Annotationen, die in Java EE 5 verwendet werden und unter anderem für Dependency Injection genutzt werden, also zum Beispiel @Resource. Damit bietet auch Spring dieses Konfigurationsverfahren an.

Dieser Schritt bedeutet nicht, dass Spring das EJB 3 Modell übernehmen wird. Die Konfiguration von Dependency Injection über Annotationen, wie sie in EJB 3 vorgenommen wird, ist nicht der Weisheit letzter Schluss, weil so die Komponente selbst ihre Konfiguration kennt. Eigentlich sollte (trivialerweise) die Komponente von außen konfigurierbar sein und nicht die Konfiguration in sich tragen. Java EE geht hier den Weg, dass @Ressource nur einen Namen aus einem JNDI-Kontext enthält, so dass dadurch die Konfiguration von außen durch Änderungen im JNDI-System möglich ist. Was allerdings passiert, wenn man die Komponenten in einer Java SE Umgebung ohne JNDI zum Beispiel zum Testen laufen lässt, ist offen. Hier ist Spring eleganter, da der Code vollständig von Konfiguration frei ist und auch kein JNDI benötigt.

Noch erstaunlicher (aber auch nicht Teil von JSR 250) sind die @Interceptor Annotationen von EJB 3. Sie sollen aspektorientierte Programmierung (AOP) einführen. AOP dient eigentlich dazu, ein Querschnittsbelang wie z.B. Tracing oder Security allen Klassen hinzuzufügen, für die dies notwendig ist. Mit EJB 3 muss man leider die Klassen selbst mit der Annotation @Interceptor versehen, was das Prinzip ad absurdum führt: Die Klasse soll ja gerade frei von dem Belang sein. Ich habe auch schon Code gesehen, der dann in dem Interceptor schaut, ob die Klasse bzw. Methode eine Annotation hat. Das kann man statisch entscheiden und muss es nicht bei jedem Methodenaufruf tun, denn so entsteht ein unnötiger Overhead. Natürlich sind Spring AOP und AspectJ zu solchen Optimierungen in der Lage und auch die Definition einer Reaktion auf eine Annotation ist wesentlich einfacher.

Elemente wie @PostConstruct oder @PreDestroy hingegen sind vielleicht keine so schlechte Idee: Sie legen fest, welche Methode am Ende des Lebenszyklus aufgerufen werden sollen bzw. nach dem Erzeugen der Objekte.

Ingesamt geht es hier also um das, worum es bei Spring schon immer gegangen ist: Freiheit. Die Nutzer von Spring können nun auch JSR 250 Annotationen verwenden, wenn sie dies wollen. Ob das wirklich einen Vorteil bringt, ist eine andere Frage...

PS: Code-Beispiele gibt es hier.  ¶ 11:25