JAXenter.de

Das Portal für Java, Architektur, Cloud & Agile
X

#Docker-Woche auf JAXenter: Top-Artikel, Tutorials & Videos in unserem Docker-Special!

JavaEE versus Spring: Hitzige Debatte um Arun Guptas Legacy-Vorwurf

Hartmut Schlosser

Vielen Dank an Spring dafür, die Zeit überbrückt zu haben, in der Java EE noch nicht Enterprise-tauglich war. Und dafür, in dieser Zeit Funktionalität bereit gestellt zu haben, die jetzt in den Mainstream Java EE 6 Application Servern integriert ist.

Mit dieser Danksagung beginnt Arun Gupta, Java EE & GlassFish Evangelist bei Oracle, seinen Blogeintrag "Why is Java EE 6 better than Spring ?". Und nicht unschwer ist der etwas höhnische Subtext herauszuhören: "Spring - das war gestern, die Zukunft gehört Java EE".

Ein weiterer unrühmlicher Vergleich folgt auf dem Fuß:

Spring = Struts 2003. Revolutionär zu seiner Zeit, heute Legacy.

Wie kommt Arun zu diesen Aussagen?

Spring Cleanup

Arun vergleicht zwei Anwendungen, die mit Hibernate und MySQL CRUD-Operationen auf eine Datenbank-Tabelle ausführen - einmal entwickelt mit Spring (auf diesem Blog) und einmal von Arun selbst geschrieben mit Java EE 6. Abgesehen davon, dass die NetBeans-Wizards die Java-EE-Anwendung in einigen Minuten hervorgezaubert hätten, zeige die Java-EE-Version einen deutlich kleineren Footprint. Arun legt zum Beweis folgende Tabelle vor:



Das Spring-basierte WAR File ist in dem Vergleich 516 Mal größer, die Deployment-Zeit gerate dadurch beim ersten Durchgang doppelt so lang, bei weiteren Deployments 10 Mal so lang wie bei der Java-EE-Variante.

Arun zählt dann eine Reihe von Sachverhalten auf, die JavaEE seiner Meinung nach Spring überlegen macht:

  • Während essentielle Funktionalität wie Security, Persistenz und Dependency Injection bei Java-EE-6-Servern von Haus aus mit an Bord sei, müssten diese Features mit Spring individuell eingerichtet und gepatched werden. Das Ergebnis: Spring-Anwendungen führten schnell zu einer "Stack-Explosion".
  • Während Java EE 6 Server intensiv gegen eine Vielzahl von Plattformen getestet wurden, liege bei Spring die Testarbeit gegen die verschiedenen JDKs, Betriebssysteme und Patches in der Verantwortung des Spring-Entwicklers.
  • Noch leichtgewichtiger werde Java EE 6 durch das Web Profile, eine Untermenge der JavaEE-Specs, denen Spring nichts entgegenzusetzen habe. Es existiere zwar der VMware tcServer, dieser sei aber kein Standard und in keiner Weise zertifiziert.

Als weitere Vorteile von Java EE zählt Arun auf:

  • Wahlfreiheit zwischen mittlerweile 14 Java EE 6 zertifizierten Containern
  • Freie Wahl des Anbieters (im Gegensatz zum Vendor-Lockin mit Spring bzw. VMware)
  • Support: Mit Spring benötige man typischerweise Support von zwei Anbietern: VMware und dem Container-Anbieter (außer man nutzt wirklich den tcServer). Mit Java EE bekomme man alles aus einer Hand
  • Mit Spring baue man sich typischerweise eine eigene Distribution mit verschiedenen Jars zusammen. Die Integrations- und Testarbeit bleibe indes am Spring-Entwickler hängen. Im Gegensatz zu Java EE, wo diese Arbeit vom Server übernommen werde.

Aruns abschließende Message an Spring-Anwender:

The complexity in J2EE 1.2, 1.3, and 1.4 led to the genesis of Spring but that was in 2004. This is 2012 and the name has changed to "Java EE 6" :-) There are tons of improvements in the Java EE platform to make it easy-to-use and powerful. Arun Gupta

Arun rät deshalb zum "Frühjahrsputz" - englisch "Spring Cleanup", und meint damit die Migration vorhandener Spring-Anwendungen nach Java EE.

Move away from your legacy Spring-based applications to a lighter and more modern approach of building enterprise Java applications using Java EE 6. Arun Gupta

Argumente für Spring

Dass ein solch offensiv ausgeführter Anti-Spring-Blogeintrag nicht unbeantwortet bleiben würde, ist klar. Ohne den aggressiven Ton Guptas fortzuführen, stellt Kommentator Oliver Gierke (alias "Ollie") einige Punkte heraus:

  • Die große Anzahl an Jars im von Arun Gupta zitierten Spring-Projekt ist kein Muss, sondern auf unprofessionelles Entwickeln zurückzuführen. Der Vorteil des Modulcharakters von Spring liege gerade darin, dass man die nötigen Jars aussuchen, die unnötigen weglassen könne - ohne ein monolithisches Jar-Ungeheuer mitschleppen zu müssen.
  • Java EE Updates seien üblicherweise keine einfachen Drop-in Replacements wie bei Spring, sondern benötigten den Einbezug des Operator-Teams.
  • Portierbarkeit: Auch Spring ist hochgradig portierbar, etwa ist es möglich, JPA2 mit einem Tomcat 5 einzubinden. Im Übrigen sei das Argument "Portierbarkeit" ohnehin dem Bereich der Mythen zuzuordnen: Jede nicht-triviale JPA2-Anwendung von JPA Provider A auf JPA Provider B zu portieren, ist nicht ohne großen Aufwand möglich. Die Realität: Die wenigsten laufenden Systeme werden überhaupt migriert.
  • Spring-Anwendungen laufen auf allen JavaEE-Container und können von der gesamten JavaEE-Infrastruktur Gebrauch machen. Wahlfreiheit ist also mit Spring gegeben.
  • Das Spring-Ökosystem hat zudem jede Menge zusätzlicher Technologien zu bieten, die weit über den Scope von Java EE hinausreichen: Ein Standard wie JavaEE löse definitionsgemäß die Probleme von gestern, Spring schaue nach vorne. Beispielsweise auf die NoSQL-Welt, auf Big Data, auf die sozialen Netzwerke.

With JavaEE you usually have to hope not to suddenly face a requirement that's not covered by the standard. Of course you can go library again then but off goes your consistency Ollie

Spring strikes back

James Bayer von SpringSource spricht in seinem Antwortblog: "Arun Gupta Java EE 6 and Spring Response" eine deutliche Sprache: Als ausbalancierte Analyse könne man Arun Guptas Vergleich sicherlich nicht verkaufen. Wer so gegen das populärste Java-Framework wettere, müsse mit stichhaltigen Argumenten kommen. Guptas tendenziöse Darstellung aber gleiche eher einem Troll-Eintrag:

I'm really surprised to see you trolling Spring like this. James Bayer

Bayer wirft Gupta vor, sich vor den Marketing-Karren der JavaEE-Anbieter spannen zu lassen.

I guess if you're paid to travel around the world telling people not to use the most popular Java framework that you need to come up with reasons. From what I can tell the people screaming the hardest not to use Spring are mostly authors employed by vendors that have a strong interest to lock-in their customers to full Java EE server instead of a framework that lets them (but not requires them!) to run on a Servlet or Java SE container. James Bayer

Besonders das Attribut "Legacy" kann Bayer nicht auf sich sitzen lassen.

I find it very strange that you try and attach a "l"-word attribute to Spring when the major app server vendors have not even been shipping full Java EE 6 releases until so recently that almost no customers have the latest versions of WebLogic, WebSphere or JBoss installed. James Bayer

Come on Arun! You can do better!

In der Tat ist der aggressive Ton, den Arun Gupta anschlägt, unverständlich. Der Vergleich "JavaEE oder Spring" - ohnehin 100 Mal wiedergekäut - gewinnt durch verbale Entgleisung und persönliche Angriffe nicht an Tiefe. Feststellen lässt sich seit Java EE 6 sicherlich eine Renaissance von JavaEE. In einer kürzlich durchgeführten JAXenter-Umfrage lag JavaEE mit 46% knapp vor Spring (34%) - ein Verhältnis, das vor zwei Jahren noch umgekehrt ausgefallen wäre.

Unsere EnterpriseTales-Kolumnisten Lars Röwekamp und Matthias Weßendorf hatten zum Start ihrer Kolumne 2011 die Reichhaltigkeit des Spring-Ökosystems hervorgehoben und das folgende Fazit gezogen:

Trotz bestehender Alternativen bestimmen Java EE und Spring den Enterprise-Java-Markt fast vollständig. Und wie so oft gilt: "Wer die Wahl hat, hat die Qual!". Während sich beide Frameworks im Kern kaum noch unterscheiden, rückt das "Rundherum" immer stärker in den Fokus. Hier hat Spring mit seinen mittlerweile fast 20 Projekten ganz eindeutig die Nase vorn. Egal ob Enterprise-Integration, NoSQL-Datenbanken oder die Cloud - Spring bietet eine Lösung. Doch alles hat seinen Preis. Und der heißt in diesem Fall 100%ige Abhängigkeit.

Ein Jahr später stellen die beiden in ihrer jüngsten Kolumne fest, dass JavaEE einigen Boden gut gemacht hat.

Java EE 5 und 6 sind erfolgreich in der Realität angekommen und machen Mitbewerbern wie Spring das Leben schwer.

Der wachsende Erfolg von Java EE in den letzten Jahren hat viele Gründe:

  • Eine starke Vereinfachung der gesamten Plattform (z. B. EJB Lite)
  • Bereitstellung von optimal auf ihre Zielgruppen abgestimmten minimierten Profilen (viele Container bieten lediglich nur das Web Profile von Java EE an)
  • Einführung neuer und leistungsstarker Technologien (wie beispielsweise CDI)
  • Statt unproduktive Flame Wars wünschen wir uns solche fachlichen Vergleiche - gerne auch als Kommentar zu diesem Beitrag. Im Übrigen denken wir wie Bayer, dass das Java-Ökosystem Besseres verdient hat als oberflächliche Marketing-Texte, besondere wenn sie von verdienten Java-Veteranen wie Gupta kommen.

    I don't understand the Java EE vendor mentality that encourages deriding Spring when so many developers use it effectively and like it. Go ahead and cheer for your team, but to misrepresent what you see as the other team's case is disingenuous. I personally find it very deflating to the Java community as a whole when you, Bill Burke and others write trolling articles. James Bayer

    Come on Arun, das ist doch nicht dein Niveau! Wir sind sicher, du kannst es besser!

    Verwandte Themen: 

    Kommentare

    Ihr Kommentar zum Thema

    Als Gast kommentieren:

    Gastkommentare werden nach redaktioneller Prüfung freigegeben (bitte Policy beachten).