Die häufig gestellte Frage, ob Java EE oder Spring eingesetzt werden soll, muss man m. E. auf den vergleichbaren Bereich beider Welten eingrenzen: Es geht hier um die Plattform von Enterprise-Anwendungen, d. h. im Kern um den Dependency Injection Container. Hier hatte J2EE ganz deutliche Schwächen, die in meiner Vorstellung das Spring Framework erst richtig interessant und vorteilhaft gemacht haben. Java EE 6 hat hier aber ganz erheblich nachgelegt und bietet mit CDI einen extrem einfachen und leistungsfähigen Mechanismus zur kontextbasierten Komposition von Anwendungsbausteinen an – und das in nahezu allen Fällen ohne explizite Konfiguration. Die „Schmerzen“, die seinerzeit den Einsatz von Spring nahegelegt haben, sind also nicht mehr vorhanden.
Für den Einsatz von Java EE 6 spricht, dass es abgestimmte und verbindliche Spezifikationen gibt, die eine Stabilität der Anwendungen auch über Versionswechsel hinweg ermöglichen. Im proprietären (= nicht-standardisierten) Bereich ist das nicht so leicht zu garantieren, wie uns bspw. die Historie von Struts vor Augen führt. Sehr positiv finde ich weiterhin die Existenz mehrerer unabhängiger Java-EE-Implementierungen (auch wenn wir für das Full Profile noch ein wenig Geduld aufbringen müssen), wodurch ein Vendor Lock-In im Ansatz abgewehrt wird. In dem Zusammenhang ist uns die (zwar schnell entschärfte) Ankündigung von SpringSource im Herbst 2008, Maintenance Releases kostenpflichtig zu machen, noch gut in Erinnerung.
Die gemachten Überlegungen gelten natürlich nur für Projekte, die noch vor der Auswahl der Plattform stehen – es lohnt nicht, bestehende Software umzubauen. Wenn man mir aber für neue Projekte die Eingangsfrage stellt, entscheide ich mich für die einfache Variante: Java EE 6.
