Immer wieder muss man Artikel lesen die einen Titel wie dieser Blog Eintrag haben und jedes Mal amüsiere ich mich darüber, wie emotional dann die Diskussionen geführt werden.
Im der aktuelle Ausgabe des Java Magazin (4.2011 ) habe ich dann in der Kolumne „EnterpriseTales“ folgende Empfehlung der Autoren gelesen:
Generell ist unsere Empfehlung daher, so lange auf den Standard zu setzen, bis etwas explizit dagegen spricht.
Mit Standard war übrigens Java EE 6 gemeint, der im Artikel ausführlich mit Spring verglichen wird.
Für mich stellte sich sofort die Frage: Ist Java EE 6 wirklich der Standard für Enterprise Entwicklung? Was ist überhaupt ein Standard? Wikipedia formuliert das wie folgt:
Ein Standard ist eine vergleichsweise einheitliche oder vereinheitlichte, weithin anerkannte und meist auch angewandte (oder zumindest angestrebte) Art und Weise, etwas herzustellen oder durchzuführen, die sich gegenüber anderen Arten und Weisen durchgesetzt hat.
Seit 1996 entwickle ich mit Java und seit 1999 auch mit der Java Enterprise Edition. Einige „Standards“ daraus würde ich auch tatsächlich als „Standard“ bezeichnen: Beispielsweise die Java Servlet Specification . Servlets sind über die Jahre nur im Detail verändert worden und es gab kaum Migrationsaufwände in Projekten. WAR Archive, web.xml, die Interfaces sind evolutionär weiterentwickelt worden (beispielsweise war die Einführung von Servlet Filtern ein echter Gewinn) und Servlets wurden in fast allen gängigen Web Framework in Java als zentrales Element genutzt. Zusätzlich gibt es eine Menge stabiler Servlet Containern/Application Server, die diesen Standard schnell und stabil umgesetzt haben (Tomcat , Jetty, JBoss , Weblogic, WebSphere , …).
Bei vielen anderen so genannten Standards in Java EE (oder früher J2EE) kann ich nicht so positiv zurück blicken. Der Enterprise JavaBeans Standard beispielsweise ist für mich persönlich ein Desaster gewesen. Wer 1999 auf EJB 1.0 gesetzt hat, kann bis heute auf eine lange Historie von Migrationen zurückblicken. EJB 1.0 nach EJB 1.1 – keine Kompatibilität. EJB 1.1 nach EJB 2.0 – keine Kompatibilität. EJB 2.0 nach EJB 3.0 – keine Kompatibilität. Die Unterstützung durch aktuelle Application Server, war meistens lange nicht gegeben – performant funktionierte EJB dann meistens sowieso nur durch Hersteller spezifische Erweiterungen. Zudem musste eine ganze Reihe von Patterns beachtet werden, damit eine Anwendung überhaupt funktionieren konnte. Von der Testbarkeit dieser Standards wollen wir jetzt hier gar nicht reden.
Seit Jahren läuft der Java EE Standard aktuellen, etablierten Frameworks hinterher und ist dann häufig doch nur eine politische Kompromisslösung. Auch das beliebte EJB3 bzw. JPA ist so ein Beispiel. Mal ganz ehrlich: JPA 1.0 war ja ganz nett, aber den Status „Enterprise“ hatte es wohl nicht verdient. Ein O/R Mapping ohne 2nd Level Cache? Lustig. Im Vergleich zu Hibernate oder EclipseLink konnte ich keinen Vorteil erkennen – außer das es ein selbst ernannter Standard ist – na und? Wo ist der Vorteil? Man kann auch mit Hibernate auf jedem Application Server (und sogar in Tomcat etc.) deployen – ist das dann nicht auch ein Standard? Hibernate bietet dann noch zusätzlich unzählige Verbesserungen und Erweiterungen – wie lange wird es dauern, bis der „Standard“ diese auch implementiert?
Bei anderen Themen hinkt der Standard sowieso wieder Lichtjahre hinterher – JSF ist so ein Beispiel. Im Vergleich zu GWT oder Vaadin sieht JSF doch aus wie aus der Steinzeit. Über das Laufzeitverhalten von JSF (Stichwort: Speicherverbrauch ) sollte man auch besser Stillschweigen bewahren.
Mal ganz ehrlich wer kennt überhaupt einen Java EE 6 Application Server in Produktion einer unternehmenskritischen Anwendung? Ich habe auf jeden Fall noch keinen gesehen – viele sind ja froh, wenn Java EE 5 unterstützt wird.
CDI (Java EE 6) vs Spring ist für mich eine ähnliche Diskussion. Spring bietet seit Jahren einen ausgereiften, stabilen IOC Container, der kontinuierlich und vernünftig weiterentwickelt wird. Trotzdem hat man in Projekten keine Migrationsaufwände. Ein Featurevergleich ist da aus meiner Sicht garnicht notwendig.
Das Zitat aus dem JavaMagazin Artikel möchte ich deshalb noch mal aufgreifen:
Generell ist unsere Empfehlung daher, so lange auf den Standard zu setzen, bis etwas explizit dagegen spricht.
Das kann ich nur unterstützen, aber Java EE 6 ist kein Standard, weil es sich eben nicht „gegenüber anderen Arten und Weisen durchgesetzt hat“. Teile von Java EE sind sicherlich Standard (wie schon erwähnt z.B. die Servlet API) – andere werden in den nächsten Jahren erst unter Beweis stellen müssen, das Sie ein Standard sind, stabil bleiben und breite Unterstützung finden. Selbst Adam Bien (ein beliebter Speaker und Freelancer der Java EE 6 ) schreibt im selben Java Magazin (Seite 52):
CDI ist noch nicht so weit.
In CDI fehlen aber noch entscheidende Aspekte wie Transaktionalität oder asynchrone Verarbeitung welche im EJB 3.1 vorhanden sind. Man könnte zwar alles in CDI nachbauen, eine minimalistische Lösung wäre jedoch die Kombination von EJB 3.1 mit CDI in Java EE 6 (siehe z.B. http://www.oracle.com/technetwork/issue-archive/2011/11-jan/o11java-195110.htm …”
“…
So richtig abheben könnte CDI mit Java EE 7. Es könnten hier die “exklusiven” EJB 3.1 Aspekte der Allgemeinheit zur Verfügung gestellt werden
…”
Wenn dem so ist, dann brauchen wir über Java EE vor 2015 ja nicht wirklich nachzudenken. Deshalb bleibt für mich Spring die erste Wahl in unseren Projekten und wir werden Java EE weiter beobachten.
War dieser Beitrag hilfreich?
Weitere Beiträge
von Mirko Novakovic
21.2.2014 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Mirko Novakovic
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.