Das Problem mit Java EE oder: Die reale Realität vs. die Konfernenz-Realität Wenn man Konferenzen besucht und sich Vorträge anhört, bekommt man leicht den Eindruck, dass Java EE eine ernsthafte Alternative zu Spring ist und vor allem - es ist ja im Application Server enthalten, warum also Spring nutzen? Dabei ist die Rede natürlich von Java EE 5 und dem noch nicht fertig spezifizierte Java EE 6. Diese Standards haben neue Programmiermodelle eingeführt - über die Probleme von Java EE 1.4 und EJB 2.x braucht man wohl nichts zu sagen.

Interessanterweise hat diese Konferenz-Realität aber nichts mit der realen Realität zu tun, die da draußen in den Projekten wirklich gelebt wird. Zunächst einmal sagen zahlreiche Statistiken, dass Tomcat die führende Java-Plattform ist. So zeigt der JAXenter Quick Vote zum Beispiel, dass 58% aller Java-Entwickler Tomcat als Basis aller Web-Projekte verwenden, 24% gelegentlich je nach technischer Entscheidung und 12% gelegentlich je nach politischer Entscheidung - zusammen 94%. Das 2008 Evans Data Survey geht von 68% Markt-Anteil von Tomcat aus. Das TheServerSide Survey kommt zu ähnlichen Ergebnisse. Ingesamt arbeitet die Mehrheit der Java-Anwendung also mit Tomcat und hat daher keine vollständige Java-EE-Umgebung. Sie können oder wollen also nicht die vollständigen Java-EE-APIs nutzen. Es kann auf keinen Fall die Rede davon sein, dass man die Java-EE-APIs "eh schon im Application Server hat". Das Gegenteil ist der Fall - der Java-EE-Application-Server ist die Ausnahme, nicht die Regel. Und selbst wenn einer genutzt wird, ist es oft eine alte Version, die noch kein Java EE 5 unterstützt. Der Betrieb ist eben eher konservativ. Java EE 6 ist noch nicht einmal fertig standardisiert - es macht also wenig Sinn, das weiter zu betrachten.

Diese Wahrnehmung spiegelt sich auch in konkret in letzter Zeit erlebten Projekt-Szenarien wieder:

• So das Projekt, das zwar auf einem vollständigen Java-EE-Server läuft, aber auf JDK 1.4. Java EE würde hier EJB 2.x anbieten, was niemand wirklich will. Die einzige sinnvolle Alternative ist also Spring.


• Oder das Projekt, dass auf einer Standard-Software aufbaut. Die läuft auf einem gebundelten Tomcat - der eben kein vollständiges Java EE anbietet. Selbst wenn man wollte, kann man kein vollständiges Java EE nutzen.


• Oder das Projekt, das von EJB 3 wegmigriert, um auf Tomcat umzusteigen - weil man Tomcat als gegenüber Java EE als Ablaufumgebung vorzieht.

Die Realität im Java-Bereich ist, dass eine vollständige Java-EE-Unterstützung - im Gegensatz zu dem Stand vor einigen Jahren - bei Enterprise-Anwendungen keine große Rolle mehr spielt. Und ich denke, dass sich dieser Trends aufgrund der Dominanz von Tomcat und dem OSGi-Aufschwung noch weiter verstärken wird.

Labels: Java EE, Spring, Tomcat

  ¶ 11:30