Java EE vs Spring. Oder: Was ist eigentlich ein Standard?

15 Kommentare

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.

 

Als Mitbegründer und Advisor der codecentric AG berät Mirko bei der strategischen Ausrichtung des Unternehmens. Er ist Geschäftsführer und Mitgründer der Startups CenterDevice und Instana – beides disruptive Geschäftsmodelle auf Basis von Big-Data- und Cloud-Technologien.

Seine Interessen liegen im Bereich der Veränderung von Geschäftsmodellen durch moderne Technologien und Software, also der zunehmenden Digitalisierung der Welt und den daraus resultierenden Veränderungen und Potential für Unternehmen.
Im Privatleben widmet er sich am liebsten seiner Familie, zum sportlichen Ausgleich fährt er Mountainbike.

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Kommentare

  • Adam S.

    12. März 2011 von Adam S.

    Mirko, are you going to publish an english version of this post ?

  • Mirko Novakovic

    16. März 2011 von Mirko Novakovic

    Grzegorz, I can see the same situations at a lot of customers. Most of them still using a WebSphere 6.x version – with plans to migrate to WebSphere 7 for month. They have fear how much migration effort it will take – especially if they have Java EE applications with EJB 2.x etc.

    But I know the arguments: We pay so much money for the AppServer, so you have to utilize the „standard“…

  • Mirko Novakovic

    16. März 2011 von Mirko Novakovic

    Hi John,

    for sure neither JEE nor Spring are evil or bad. The question was if you can generally claim that it is better to use Java EE as it is a „standard“. I say: No, you have to carefully look into the APIs and their stability. Servlet, JMS etc. are stable and standard. But „standards“ like CDI should be chosen carefully in my opinion as they could change which mean that you have migration efforts. Therefore I would recommend defacto standards like Spring in these cases and would investigate how CDI evolve.

    Another example: If I would have the requirement to develop a rich internet application, I wouldn’t chose JSF as I would say that frameworks like GWT or Vaadin are more suiteable and mature for this use case – even if they are not part of the Java EE standard.

    Mirko

  • Mirko Novakovic

    17. März 2011 von Mirko Novakovic

    Hi Antoine,

    Seems that you got me wrong. As I stated in a previous comment, I am not saying that Java EE is useless and you shouldn’t care. What I am saying is that you should not chose the standard just because it is a self called standard. Spring is just an example – I would also chose Hibernate in favour to just JPA. (I would use JPA + Hibernate as JPA is missing a lot of enterprise features)

    I am happy that Java EE going into the right direction and hope that it will continue like that. And with politics I would say that you are joking…are you really saying that SpringSource is less open than Oracle who leads almost all Java EE standards? 🙂

    Mirko

  • Mirko Novakovic

    17. März 2011 von Mirko Novakovic

    Antoine,

    The statement from Adam Bien is taken 1:1 out of the current Java Magazine April 2011. The statement seems volatile…does the maturity of a standard really correlate to a bug one implementation?

    Mirko

  • Mirko Novakovic

    17. März 2011 von Mirko Novakovic

    Hi Adam,

    Thank you for correcting the statement I took of the Java Magazine. There is an article on page 52 (wich dass that it is from you) with the headline: CDI ist noch nicht so weit. I translated it to CDI is not ready yet – which is correct in my point of view.

    So sorry if this have not been your words – I didn’t want to citate you wrong…it’s a 1:1 citate of a current magazine. I will correct this later as I am currently in the hospital getting our 3rd baby and my wife is not happy that I am playing with my Android 🙂

    Mirko

  • Mirko Novakovic

    17. März 2011 von Mirko Novakovic

    Adam,

    I’ve put in the whole statement. I just liked that you point out that there is still room for improvement in CDI – which is what I wanted to say with my article.

    In fact CDI is a „1.0“ version of a framework/API and it is normal that 1.0 versions will be enhanced in the future. Hope the correction is ok for you.

    And by the way: Even if you say you are not an evangelist, you should see my developers coming out of one of your session – it’s always hard to convince them not to throw away the whole code and reimplement it in Java EE 6 😉

    Now turning of all internet ready devices and will help my wife to do a good and healthy deployment 😉

    Mirko

  • Mirko Novakovic

    17. März 2011 von Mirko Novakovic

    Hi Antonio,

    thank you for the very good comment. I also agree with you that Java EE is going into the right direction – especially from a developers point of view. As I said I am using lots of Java EE standards for years (servlet, JMS, JSP, etc) and now even JPA (but always in combination with Hibernate – even in JPA 2.0 I have the 2nd level cache, but I miss the query cache in some situations).

    In the last years I combined it with Spring – which works fine with most of the Java EE standards, including EJB3 or JSF. From an architects point of view it was a good choice to do that: Very stable. Testable. No migration. Runs on every server. So I don’t see a reason to switch to CDI for dependency injection – and Spring has lot’s more of features/APIs I would use. (e.g. Spring Batch is great as you said and we are using it in lots of our projects)

    I have not followed the JSRs and the discussions with Rod Johnson, Gavin King, etc in detail – but I think your are right that it needs courage to do a good standard. (I also liked the JBoss Seam approach which had some nice concepts that are now part of Java EE 6 and I think it is a good idea to standardize these features)

    Mirko

  • struberg

    2. Mai 2011 von struberg

    Hi!

    It happens that I have a Java EE6 application running since January 2010 (right, 2010 not 2011)! The app was finished in September 2010 and now serves 5 mio page hits/d with peeks up to 12000 pages/minute.

    https://tiss.tuwien.ac.at/curriculum/studyCodes.xhtml

    The whole stack is built upon
    * Apache Tomcat
    * Apache OpenWebBeans as CDI container (I’m happen to be one of the main commiters which made it a bit easier)
    * Apache MyFaces 2
    * Apache BVAL
    * Apache OpenJPA2
    * JUEL (a slightly patched version see http://github.com/struberg/juel )
    * PrimeFaces2 to some degrees

    Btw, the parts you see are only the ‚public‘ ones. If you would login as lecturer, student or university employee (dekan, secretary, cleaning personal – we have 40.000 distinct users) you would see a lot more menus. We basically cover the whole business processes from creating study plans, room planing over holding all the courses and finally also do the payment stuff and similar things. Not to mention that we needed to migrate almost 50 years of university data and talk to a few separate SAP installations, etc…

    And we did all this in 8 months after another team spent 3 years with ruby (the team was/is actually pretty good, but ruby is simply not ready for such apps).

    LieGrue,
    strub

  • struberg

    2. Mai 2011 von struberg

    btw, there is a comparison of spring vs OWB vs Weld available:
    http://os890.blogspot.com/2011/03/benchmark-request-scope-owb-vs-weld-vs.html
    http://os890.blogspot.com/2011/03/benchmark-myfaces-codi-scopes-codi-vs.html

    we tried to convert one of our ‚fat‘ pages from OWB to spring. The rendering time on the server rose from 420ms to over 2 seconds…

    LieGrue,
    strub

    PS: fat page means 1600 study points in a h:datatable – please don’t ask why they needed it that way! (tip: Universitätsgesetz…)

  • mcahornsirup

    A couple of weeks ago I started to dive into the Spring world… and it seems like they try to solve everything by making everything springish… there might be good reasons for every design decission they made, but by generalizing and abstracting everything away, it gets much more complicated. Even simple things are getting more difficult. e.g. if you want to implement a Filter, you can’t do it the JEE way, you need to use a SpringProxySomethingDelegationBean… argh!

  • Fatih Zorlu

    28. Februar 2014 von Fatih Zorlu

    Also wenn ich mir diesen Artikel lese, kann ich nur den Kopf schütteln, es ist eine Schande dieser Leute JEE als nicht Standart zu nennen, kein Wunder die meisten Fehlschüsse und Desaster an Prjekten kommen nur von solchen Leuten die immer nicht verstanden haben was Java ist. Ihr lebt alle in Vergangenheit und Spring ist schrott -> Konfigurationsoverlow, fehlerhaft und macht mittlerweile auch JEE nach und hat so oder so nichts mit Enterprise-Entwicklung zutun zumal im Artikel was von ejb1.0 steht, ja mein lieber mann in Java sind sogar tools die vor 2 Jahren rauskamen schon veraltet „wie kannst du nur sowas vergleichen“? JEE IST EIN STANDART UND SPRING IST WAS FÜR VERSAGER

  • Fatih Zorlu

    28. Februar 2014 von Fatih Zorlu

    noch Ergänzung, bitte schreibt über JAVA und JEE was rein wenn ihr euch darin auskennt, spring ist nicht mal ansatzweise konkurrenzfähig mit JEE !!! Alle Argumente die im Artikel gegen JEE aufgezählt werden sind lachhaft und amateurhhaft.

  • Mirko Novakovic

    28. Februar 2014 von Mirko Novakovic

    Hallo Fatih,

    ich denke, dass Du den Artikel nicht verstanden hast. Beispielsweise geht es nicht um EJB 1.0, sondern darum in der Historie zu betrachten, wie stabil ein „Standard“ gewesen ist. Stabilität ist sicherlich ein Kriterium für die Auswahl eines Standards – sicherlich nicht für jeden Anwendung, aber glaube mir, es gibt Anwendungen die länger als zwei Jahre laufen und so groß sind, dass man sie nicht einfach umbauen kann. Bei Banken und Versicherungen sind 20 Jahre für die Lebensdauer einer Anwendung keine Seltenheit und die Kosten für Anpassungen riesig.

    Du wirfst zudem vor, dass keine Argumente im Artikel sind, ohne selber auch nur ein Argument für Deine absurden und unqualifizierten Äußerungen zu nennen.

    Hast Du z.B. ein Argument dafür, dass JSF ein gutes Web Framework ist? Oder das es besser ist als Vaadin, AngilarJS oder Spring MVC? Hast Du dich mal mir dem Session Handling von JSF beschäftigt und dir z.B. mal einen Heapdump davon angeschaut? Oder anders: Weißt du was ein Heapdump ist und wie man Ihn auswertet?

    Grüße
    Mirko

  • Marco P

    19. Juni 2014 von Marco P

    Leute wie Fatih verderben gute Blogs,Foren & Diskussion. Sein Posting könnte getrost gelöscht werden, da es ohnehin keinen added value darstellt.

    Kompliment Mirko, cool geblieben selbst in der Diskussion mit Reza, wäre mir wahrscheinlich nicht gelungen.

    Wir sind Standard Softwarehersteller in der Finanzindustrie. Als solche haben wir ein Selbstverständnis Software zu bauen die auch in 5 Jahren noch läuft, erweiterbar sein soll und unsere Wartungseinnahmen profitabel sein müssen.

    Die historische Aufarbeitung von Mirko des J(2)EE ist meiner Meinung nach völlig korrekt und alle die EJB 1.0/2.1 Standards usw. migrieren durften werden wissen, dass das nicht ganz gratis zu haben war.

    Vom Argument „Standard“ – ob offen, technisch, de-facto – kann ich mir nur dann was kaufen, wenn das ein komparativer Vorteil bringt. Für „lustig“ wechselt doch keiner sein Appserver. Was kann ich mir also davon kaufen einen Standard einzusetzen? Zählt das bei Euch? Verkauft Ihr deswegen mehr Software? Könnt ihr dadurch einfacher neue qualifizierte Kollegen einstellen?

    Aktuell – Juni 2014 geht’s mir so, dass ich höchst sportliche time-to-market Anforderungen zu erfüllen habe. Dass ich schnell, qualitativ gute neue features raushauen muss. Ich kann nicht andauern ein re-engineering auf unsere eigene Kappe vom Stapel lassen nur um wieder der neusten Version des Standards zu folgen. Bisher setzen wir auf Spring & OSGI und sind eigentlich glücklich damit.

    Wobei mir der religiöse Teil der Diskussion ob nun JEE/Appserver oder Spring nichts nützt. Wir haben halt seit EJB2.1 Erfahrungen auf Spring gewechselt und bisher keinen Grund irgendwas daran zu ändern. Auch die Tatsache, dass Glassfish in der Zwischenzeit auch OSGI könnte ist zwar nett, bringt aber keinen Vorteil – dass der das jetzt „auch“ kann.

    Zu neuen Kollegen: wir sind gerade daran neue Kollegen anzustellen. Erstens habe ich kaum CV die Spring nicht drin hätten, ich habe aber viele CV die den Standard JEE haben: einmal mit Websphere, der andere kennt halt JBoss, Glassfish kommt zwar weniger vor ist aber auch mal vorhanden. Ich persönlich finde das nun nicht einen grossen Vorteil, dass jeder Kandidat ein Produkt kennt, das zwar einen Standard implementiert, aber halt immer ein eigenständiges Produkt ist.

    Persönlich denke ich, dass Spring „agiler“ ist, der Entwicklung voraus – was wahrscheinlich logisch ist, weil ein Standard ja erst abschliessend diskutiert und ein common sense definiert werden muss, bevor es dann noch eine Referenzimplementation gibt. Für mich ist es in meiner aktuellen Rolle einfach interessanter schneller neue Features, mehr Basisdienste zu haben, als das mir die Referenz auf ein Standard was nützen würde.

    Das ist weder als Allgemeinaussage noch als „mach ich nie“ im Kontext von JEE/Application Servers zu verstehen, sondern als Momentaufnahme.

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.