Spring versus Java EE

„Java EE 7 failed to enter the market“: Warum Spring 5 ohne Java EE 7 plant

Hartmut Schlosser

Java EE 7 ist noch nicht in der Industrie angekommen – das Spring Framework wird sich deshalb in seiner nächsten Version 5 auf die Unterstützung von JDK8 basierten Java EE 6 Server konzentrieren. Mit dieser Kernbotschaft stellt Spring-Miterfinder Jürgen Höller die Marschroute für Spring 5 vor.

Was wie eine Kampfansage an Java EE klingt, basiert auf Fakten: Während verschiedene JSRs aus Java EE 7 durchaus Akzeptanz in der Community gefunden haben (JPA 2.1, JMS 2.0, Servlet 3.1, etc.), gibt es bis dato kaum gegen Java EE 7 zertifizierte Application Server.

Weder TomEE, JBoss EAP noch Oracle WebLogic und IBM WebSphere haben bis jetzt den vollen Java EE 7 Support in ihren Produkten implementiert. Lediglich Glassfish verfügt als Referenzimplementierung über die volle Java EE 7 Funktionalität – hat allerdingt den Makel, von Oracle nicht mehr kommerziell unterstützt zu werden.

Jürgen Höller kommt zu dem Schluss: Seit der Veröffentlichung im März 2013 ist Java EE 7 kaum in Produktion zu finden. Die seit Spring 4 angestrebte Verschränkung zwischen Spring und Java EE soll deshalb zwar weitergeführt, nicht aber auf die volle Java EE 7 Plattform-Spezifikation ausgeweitet werden. Angesichts der positiven Verbreitungsraten von JDK8 und der Omnipräsenz von Java EE 6 Servern am Markt wird sich Spring 5 also an JDK 8+ und Java EE 6 Server halten.

Java EE 7 failed to enter the market

Dass Höller mit Aussagen wie „it is fair to say that Java EE 7 failed to enter the market as a platform overall“ Öl in die feurige Debatte „Spring versus Java EE“ gießt, ist offensichtlich. Prompt melden sich Kommentatoren wie das Unternehmen Payara zu Wort, das professionellen Support für Glassfish im Portfolio führt.

Das Gegenargument: Auch wenn die „großen Drei“ – Oracle, IBM, Red Hat – derzeit noch keinen vollen Java EE 7 Support anbieten können, heißt das nicht, dass Java EE 7 noch keine Produktionsreife erlangt hätte.

Now I cannot comment, nor have I got any unique insight into why the “big 3” of Oracle, IBM and RedHat haven’t released supported application servers with full Java EE 7 compatibility. However this doesn’t mean you can’t use Java EE 7 in production as this blog implies.

Zudem sei die Abqualifizierung von Glassfish als „bloße Referenzimplementierung“ nicht fair, angesichts der Qualität der Codebasis und der Entwicklungsmannschaft hinter dem Server.

Höller antwortet:

From our perspective, as long as those [Oracle, IBM, Red Hat, Anm. der Redaktion] don’t have established EE 7 editions, we can’t design a Spring Framework generation for EE 7+. This is simple market-based reasoning.

Die wenig optimistische Perspektive auf Glassfish behält Höller bei:

As for GlassFish being „just an RI“, that’s exactly what it is from Oracle’s perspective. (Note that I stated this in the Oracle section above.) And like it or not, that does matter: To the best of my knowledge, at this point, Oracle only invests into the subprojects that they’re also using in WebLogic but not into GlassFish itself. I appreciate Payara’s efforts there but it sure ain’t easy without Oracle’s backing.

Spring versus Java EE?

Wie dem auch sei: Spring orientiert sich am Markt und hat die Entscheidung gefällt, nicht blind einem Standard hinterherzulaufen, dem die Industrie-Durchdringung (noch) fehlt. Mit Projekten wie Spring Boot, Spring XD und Spring Data grenzt man sich ohnehin immer deutlicher vom orthodoxen Java-EE-Text ab. Gibt es also Grund für die Neuauflage des Spring versus Java EE Flamewars?

Eigentlich nicht. Dass die Mühlen bei Java EE langsamer mahlen, als manchen lieb ist, liegt wohl in der Natur der Sache. Innovation (Spring) und Standardisierung (Java EE) sind manchmal zwei zuwiderlaufende Prinzipien, die nicht leicht unter einen Hut zu bekommen sind. Ein reaktionsschnelles Spring-Projekt steht heute einem konservativen – manche würden sagen behäbigen – Java EE gegenüber, das nach dem Motto „Es gibt nichts Schlimmeres als eine zu früh erfolgte Standardisierung“ Dinge durchaus auch einmal aussitzen kann – man denke an die kürzlich bekannt gegebene Verschiebung von Java EE 8 auf 2017.

Das Schöne daran: Weder Spring noch Java EE sind heute geschlossene Gesellschaften. Die Interoperabilität zwischen beiden Enterprise-Familien nimmt zu, sodass man als Entwickler tatsächlich mehr Wahl im Sinne von Wahlfreiheit, als Qual im Sinne eines Vendor-Lock-ins hat.

Aufmacherbild: Fight, close up of two fists hitting each other von Shutterstock / Urheberrecht: rangizzz 

Verwandte Themen:

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Content-Stratege, IT-Redakteur, Storyteller – als Online-Teamlead bei S&S Media ist Hartmut Schlosser immer auf der Suche nach der Geschichte hinter der News. #java #eclipse #devops #machinelearning #seo. Zum Lächeln bringen ihn kreative Aktionen, die den Leser bewegen. @hschlosser
Kommentare

Hinterlasse einen Kommentar

2 Kommentare auf "„Java EE 7 failed to enter the market“: Warum Spring 5 ohne Java EE 7 plant"

avatar
4000
  Subscribe  
Benachrichtige mich zu:
Michael
Gast

> Seit der Veröffentlichung von Java EE 7 im März 2013 ist Java EE 8 kaum in Produktion zu finden.
Jo. Das überrascht aber nun wirklich nicht. Auch Java EE 9 ist dort noch nicht zu finden 😉

Oliver Gierke
Gast
Ein paar zusätzliche Bemerkungen: der Titel und auch ein paar der Zwischenüberschriften geben den Inhalt von Jürgens Blogpost leider nicht so ganz korrekt wieder. „Warum Spring ohne JavaEE 7 plant“ – das Gegenteil ist eigentlich der Fall. Das Framework unterstützt sehr viele der Spezifikationen aus JavaEE7: Servlet 3.1, JTA 1.2 (@Transactional), JPA 2.1, WebSocket 1.0 werden von Spring 4 unterstützt. Die JCache-Unterstützung in Spring ist so alt (seit 4.0), dass vielen gar nicht mehr bewusst ist, dass die Spezifikation noch in keinem offiziellen JavaEE Release enthalten ist. Tatsächlich ist es so, dass Spring für viele Projekte, die auf Application Servern… Read more »