Interview mit Oliver Gierke

„Früher galt Spring als proprietär – nun steht die Java-Welt Kopf, weil Oracle Java EE das Interesse entzieht.“

Hartmut Schlosser

Oliver Gierke

Die Verzögerungen bei der Fertigstellung von Java EE 8 haben nicht nur Auswirkungen auf Nutzer der Java Enterprise Edition. Zahlreiche andere Projekte lehnen sich eng an die EE-Roadmap bzw. die wichtigen Java-EE-APIs an – allen voran das Spring-Framework. Im Gespräch mit Spring-Entwickler Oliver Gierke gehen wir der Frage nach, was die unklare Situation um Java EE für Spring bedeutet.

Was bedeutet die Java-EE-Verzögerung für Spring?

JAXenter: Bei Java EE 8 scheint es momentan nicht so recht weiterzugehen — selbst das Exekutiv-Komitee hat jüngst dazu ein offizielles Statement verfasst. Wie siehst du als Spring-Entwickler und gleichzeitig Mitglied der JPA Expert Group die Situation von Java EE 8?

Mit Java EE 8 setzt sich fort, was sich mit Java EE 7 bereits angekündigt hatte.

Oliver Gierke: Die Beziehung zwischen Spring und dem Java-EE-Standard ist ja eine vermeintlich sehr von Konkurrenz geprägte. Wenn man sich die Sache jedoch im Detail anschaut, gab und gibt es erhebliche Synergieeffekte in beide Richtungen und die Welt ist eher grau schattiert als hart schwarz-weiß.

Zum einen setzt Spring in einigen Bereichen fundamental auf Java-EE-Spezifikationen auf, benötigt sie also: Ein Spring MVC in seiner heutigen Form wäre ohne das Servlet API nicht denkbar. Zum anderen hat das Framework schon immer die wesentlichsten Spezifikationen sehr früh unterstützt. Das JCache API — interessanterweise bis heute in keinem Java-EE-Gesamtrelease enthalten — konnte man mit dem Spring Framework schon weit vor seiner Fertigstellung nutzen, sogar auf älteren Applikationsserver-Versionen, was der Verbreitung der Nutzung des API sicher zuträglich war und ist.

Grundsätzlich zeigt sich daran, dass wir eher ein Auge auf den konkreten technischen Nutzen einzelner APIs haben und unsererseits der Fokus gar nicht so sehr auf dem Java-EE-Gesamtrelease lag, mit einer entscheidenden, kritischen Ausnahme: der Zeitplanung. Das liegt vor allem daran, dass die einzelnen APIs sich natürlich die Zeit nehmen, die sie bekommen können. Verschiebt sich also das Gesamtrelease, verschieben sich üblicherweise auch die Releases der Teilspezifikationen.

Mit Java EE 8 setzt sich nun eigentlich leider fort, was sich mit dem Java EE 7 Release bereits angekündigt hatte: Das Interesse der teilnehmenden Parteien scheint weiter zu schwinden – meiner Meinung nach, weil alle großen Spieler mittlerweile auf das Cloudgeschäft fokussieren (Oracle mit Oracle Cloud, RedHat mit OpenShift, IBM mit BlueMix, und ja, auch Pivotal mit CloudFoundry). Besonders deutlich wird das, wie bereits breit dokumentiert, daran, dass in allen Oracle geführten JSRs für Java EE 8 seit mehr als einem halben Jahr fast komplette Funkstille herrscht. JSRs mit Specleads aus andere Firmen (wie z.B. CDI mit RedHat) sehen da besser aus, sind allerdings doch auf Oracle angewiesen, da es dem Java-EE-8-Gesamtrelease vorsteht.

Hinzu kommt, dass viele der Herausforderungen, vor denen Entwickler heutzutage stehen, von gar keinem Standard abgedeckt werden: Persistenztechnologien abseits relationaler Datenbanken, all die neuen Herausforderungen, die durch den Trend zu Microservices entstehen, und so weiter. Für viele dieser Probleme gibt es bereits Lösungen, und Entwickler nutzen diese bereits. D.h. ich kann in gewisser Weise nachvollziehen, dass sich Begeisterung und Motivation in Grenzen halten, wenn man 2017 APIs für JSON Binding und einem MVC Framework als „neu“ feiern soll, um sie dann 2019 in Produktion zu nehmen.

So wenden sich Entwickler meiner Erfahrung nach wieder pragmatisch dem zu, was die Java-Plattform eigentlich essentiell ausmacht: die Verfügbarkeit von qualitativ hochwertigen Bibliotheken, die Probleme lösen, die ich jetzt habe. Dies führt aber zu genau dem Effekt, den wir jetzt beobachten: geringer werdendes Interesse an Standardisierungsprozessen, die sehr lange Releasezyklen haben — vor allem auf Implementiererseite.

JAXenter: Wie du sagst, unterstützt Spring ja schon seit jeher die Java EE APIs. Was bedeutet die Stagnation und damit zusammenhängend die unklare Java-EE-Roadmap konkret für Spring – insbesondere Spring 5?

Oliver Gierke: Der Hauptaspekt, der an Java EE 8 für uns relevant ist, ist das Servlet 4.0 API mit seiner geplanten Unterstützung für HTTP 2.0. Da eigentlich abzusehen ist, dass der JSR nicht fertig wird, bis wir Spring 5 final veröffentlichen wollen, gibt es zur Zeit intensive Gespräche mit den Teams der wichtigsten Servletcontainer (Tomcat, Jetty, Undertow), um deren Support für HTTP 2.0 erst einmal nativ zu unterstützen.

Sollte Servlet 4.0 dann irgendwann kommen, reichen wir die Unterstützung dafür sicher in einem Minorrelease nach. In Anbetracht der aktuellen Unsicherheit über Releasedaten haben wir uns entschieden, diesen Weg zu gehen. Die Herausforderungen für Entwickler warten leider nicht auf politische Spiele der Beteiligten.

Ein weiterer großer Aspekt in Spring 5 ist ja die Unterstützung für reaktive Runtimes wie Netty und ein entsprechendes, an Spring MVC angelehntes Programmiermodell. Damit schaffen wir uns und den Spring-Entwicklern etwas Beinfreiheit, um potentiell Alternativen zum klassischen Servlet-Stack evaluieren zu können.

Ich persönlich würde gern noch einige kleine Änderungen in JPA sehen, die wir schon vor JPA 2.1 diskutiert hatten, die dann aber vermeintlich zu spät für das Release waren. D.h. da sind Tickets aus 2012, bei denen jetzt fraglich ist, ob diese 2017 gefixt sein werden. Solche Releasekadenzen verringern dann leider auch jegliche Motivation, sich einzubringen.

JAXenter: Im Statement des JCP Exekutiv-Komitees wird Oracle gebeten, die Bahn frei zu machen für die Community. Denkst du, die Community könnte das auch ohne Oracle?

Faktisch hat man keinen Hebel in Bezug auf JSRs, die von Oracle geleitet werden.

Oliver Gierke: Generell finde ich es sehr gut, dass es wieder verstärkte Communityaktivität um Java EE gibt. Ich bin ja selbst Mitglied der JPA Expert Group und habe zumindest auch entfernten Einblick in die Aktivitäten z.B. der Java EE Guardians. Es gibt jedoch einen Aspekt, den ich etwas unterbetrachtet bzw. gefährlich finde: Faktisch hat man — egal wieviel Community sich bilden sollte — aus lizenzrechtlichen Gründen gar keinen Hebel in Bezug auf alle JSRs, die von Oracle geleitet werden.

Nehmen wir an, Oracle rührt sich gar nicht — die bisherigen sehr netten Aufforderungen des Exekutiv-Komitees sind ja auch komplett unbeantwortet geblieben. Dann kann man natürlich viel von Community-Support und einem Fork sprechen, faktisch nutzt das aber nichts, es sei denn, man will sich auf juristisches Glatteis begeben, wie der aktuelle Fall mit Google ja eindrucksvoll zeigt. Von daher finde ich es in gewisser Weise schwierig, Handlungsfähigkeit zu suggerieren, wo sehr wahrscheinlich gar keine ist.

Wenn die Auswirkungen nicht so weitreichend und ernst wären, könnte man der aktuellen Situation eine gewisse Ironie abgewinnen: Früher wurde der Spring Stack ja gern als vermeintlich proprietär dargestellt, weil es eben genau eine Firma gab, die hauptsächlich die Entwicklung finanziert. Der Java EE Stack hingegen war im rosaroten Bild einiger immer völlig offen und Community-getrieben. Und nun steht plötzlich die ganze Java-Welt Kopf, weil eine Firma dem Standard das Interesse entzieht und man sich exakt mit der Situation konfrontiert sieht, die man über Jahre der Konkurrenz vorgeworfen hat.

Zusammenfassend also: „könnte“ im Sinne von „ist dazu fähig“ — mit Sicherheit. In den ganzen JSRs und Implementierungen dieser arbeiten sehr viele sehr fähige Leute. Da besteht für mich überhaupt kein Zweifel. Doch „könnte“ im Sinne von „unter den gegebenen rechtlichen Bedingungen“ — ein klares Nein.

JAXenter: In der Debatte geht es ja nicht nur um Java EE, sondern auch um Oracle als Java Steward, bzw. die Rolle Oracles innerhalb des JCP. Was wäre deine Wunschvorstellung für den JCP? Markus Karg hatte in seinem Interview auf JAXenter ja die Vision einer demokratischen „Java Foundation“ an die Wand gemalt.

Oliver Gierke: Grundsätzlich sehe ich hier wieder das gerade eben geschilderte Problem. Wenn man das außen vor lässt, ist der Schwenk hin zu einem wirklich Community getriebenen Java EE sicher eine gute Sache. Auf dem Java EE BOF bei der Devoxx letztes Jahr wurde auch die Idee diskutiert, die einzelnen Teilspezifikationen organisatorisch eher wie Open-Source-Projekte zu leiten, regelmäßiger zu veröffentlichen, usw. D.h. man könnte theoretisch in einen Modus gelangen, in dem es sehr regelmäßig Updates von Teilspezifikationen gibt und man auf das Java-EE-Gesamtrelease verzichtet. Nur müsste Oracle eben auch dazu die Kontrolle über die von ihnen geführten Teilspezifikationen wie z.B. JPA abgeben.

JAXenter: Vielen Dank für dieses Interview!

portrait-1000_3-300x244Oliver Gierke ist Leiter des Spring-Data-Projekts bei Pivotal, früher besser bekannt als SpringSource. Seit über neun Jahren widmet er sich dem Entwickeln von Java-Enterprise-Applikationen, Open-Source-Projekten und ist Mitglied der JPA Expert Group. Seine Arbeitsschwerpunkte liegen im Bereich Softwarearchitektur, Spring, REST und Persistenztechnologien. Er ist regelmäßiger Sprecher auf deutschen und internationalen Konferenzen sowie Autor von Fachartikeln und des ersten Spring-Data-Buchs.
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. SEO und KPIs isst er zum Frühstück. Satt machen ihn kreative Aktionen, die den Leser bewegen. @hschlosser
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: