Dann übernahm Adrian Colyer, Chief Scientist bei Interface21 und AspectJ Project Lead. Es ging dann erstmal um Java EE 5. EJB 3 bezeichnete er als rudimentäre Implementation eines Interception und Dependency Injection Systems, das fast die Mächtigkeit von Spring 1.0 hat. Neben dem Simplified Model gibt es dann ja in EJB 3 auch das Core Model, in dem sich dann die ganzen unangenehmen Sachen auch EJB 2.1 verstecken....

Die Überschneidung zwischen Spring und Java EE 5 hält er für klein - Java EE 5 ist eine Evolution, aber kein Ersatz für ein Java EE Framework. Außerdem hat es natürlich eine JDK 1.5 Abhängigkeit, die wohl bei dem derzeitigen Stand vieler Produktionssysteme auch ein Problem ist.

Dependency Injection in EJB 3 hat das Problem, dass es auf Annotationen basiert, was für Legacy Code (also alles vor JDK 1.5, was sehr viel ist), natürlich ein Problem ist. Außerdem benutzt es JNDI und es unterstützt auch keine Features wie Konstruktor Dependency Injection.

Interceptors in EJB 3 sind nach seinen Worten ein nicht erprobtes Modell, weil es eben keine Pointcuts hat. Dadurch hat man immer noch Scattering, d.h. ein Aspekt muss man in den Klassen immer noch einweben und man kann ihn nicht so leicht auf einige Klassen limitieren. Das Modell ist dabei nicht nur weniger mächtig, sondern auch komplexer, wie Adrian an einem Beispiel aus der EJB 3 Spezifikation zeigte. Dabei hat Spring vor allem auch typsichere Advices, in denen man dann keine Type Casts mehr machen muss.

Das ganze ist aber keine entweder/oder Entscheidung - immerhin haben wir ja auch einen EJB 3 Container für BEA geschrieben. Es ist nur einfach so, dass Spring in den Bereiche, in denen Spring eine Alternative zu EJB 3 ist, überlegen ist.