Interview mit Mike Milinkovich zum Release von Jakarta EE 8

Jakarta EE 8: „Die Community hat nun endlich eine Open-Source-Grundlage, auf der die Zukunft von Enterprise Java aufgebaut werden kann“

Dominik Mohilo

Mike Milinkovich

Mehr als ein Jahr arbeitete die Enterprise Java Community gemeinsam mit etlichen Anbietern und Unternehmen sowie der Eclipse Foundation am Umzug von Java EE Open-Source-Organisation aus Kanada. Nun, da der Umzug vollzogen und Jakarta EE 8 veröffentlicht ist, sind allerdings noch einige Fragen offen und einige Entscheidungen zu treffen. Wir sprachen mit Mike Milinkovich, Executive Director der Eclipse Foundation, über das aktuelle Release, die Namespace-Problematik, Release-Zyklen und die Zukunft von Enterprise Java unter dem Dach der Foundation.

JAXenter: Hallo Mike und danke, dass du dir für dieses Interview Zeit genommen hast. Nach vielen Monaten der harten Arbeit ist Jakarta EE 8 endlich veröffentlicht worden. Es ist von den Features her identisch mit Java EE 8, was allerdings nicht bedeutet, dass dieses Release unspektakulär wäre. Kannst du vllt. ein wenig ins Detail gehen, wie groß die Auswirkung der Veröffentlichung von Jakarta EE 8 ist?

Mike Milinkovich: In einem Wort: gewaltig. Die harte Arbeit der vielfältigen Community aus Anbietern, Hunderten von engagierten Mitgliedern der Enterprise Java Community und Mitarbeitern der Eclipse Foundation kann nicht überbewertet werden. Sie alle haben gemeinsam hart daran gearbeitet, die kompletten Plattform- und Webprofile, TCKs und zudem noch das voll zertifizierte Eclipse GlassFish 5.1 als Jakarta-EE-8-kompatible Implementierung zu liefern. All dies wurde nach dem Schirm des Jakarta EE Specification Process geschaffen, einem offenen und anbieterunabhängigen Prozesses, der auf dem Eclipse Development Process basiert. Das ist eine wirklich großartige Leistung.

Mit Jakarta EE 8 hat die Community nun eine gute Open-Source-Grundlage, auf deren Basis sie gemeinsam am Vorantreiben von Enterprise Java arbeiten können. Das Ziel ist, dass die Community die Migration von Real-World-Workloads in die Welt von Containern, Microservices, Kubernetes, Service Meshes und anderen Cloud-nativen Technologien bewerkstelligt, die in der Industrie immer mehr Anklang finden und sich zunehmend verbreiten.

JAXenter: Jakarta EE 9 wird möglicherweise neue Funktionen im Gepäck haben, aber bis dies in Angriff genommen werden kann, muss die Community eine andere wichtige Frage beantworten: Wie soll man mit der Namespace-Problematik umgehen? Wird es einen “Big Bang” oder eher einen inkrementellen Ansatz geben?

Ich bin ein Fan des Big-Bang-Ansatzes zur Lösung der Namespace-Problematik.

Mike Milinkovich: Das ist eine sehr gute Frage und die ganze Sache wird aktuell noch aktiv diskutiert. Die gesamte Community wurde zur Teilnahme an den Gesprächen gebeten und während wir miteinander sprechen, läuft die Diskussion weiter. Bislang gibt es über 300 Meinungen zu dem Thema. Insgesamt scheint es so, als wäre eine leichte Mehrheit für den Big-Bang-Ansatz. Wichtig ist aber, dass wir die Binärkompatibilität erhalten – unabhängig davon, welcher Ansatz am Ende das Rennen macht.

JAXenter: Welchen der Ansätze würdest du persönlich bevorzugen?

Mike Milinkovich: Ich denke, dass ein klarer Schnitt und ein frischer Neustart im Interesse der Community wäre – ich bin also ein Fan des Big Bangs.

JAXenter: Wann genau wird es eine definitive Entscheidung hierzu geben?

Mike Milinkovich: Irgendwann in den nächsten Monaten. Die Community war schwer beschäftigt damit, Jakarta EE 8 fertigzustellen, daher ist gerade eher etwas Durchatmen angesagt, aber die Planung der kommenden Releases ist ganz oben auf der To-Do-Liste. Wir erwarten, dass sämtliche Anbieter, die in der Jakarta EE Working Group sind, ihre Java-EE-8-kompatiblen Implementierungen als Jakarta-EE-8-kompatibel zu zertifizieren, das wird ebenfalls noch eine Menge Arbeit.

W-JAX 2019 Java-Dossier für Software-Architekten

Kostenlos: Java-Dossier für Software-Architekten 2019

Auf über 30 Seiten vermitteln Experten praktisches Know-how zu den neuen Valuetypes in Java 12, dem Einsatz von Service Meshes in Microservices-Projekten, der erfolgreichen Einführung von DevOps-Praktiken im Unternehmen und der nachhaltigen JavaScript-Entwicklung mit Angular und dem WebComponents-Standard.

 

JAXenter: Ist die Namespace-Geschichte erst einmal gelöst, beginnt eine neue Ära für Enterprise Java. Gibt es bereits Überlegungen, welche Features in Jakarta EE 9 und darüber hinaus implementiert werden sollen?

Mike Milinkovich: Es gibt definitiv einen Wunschzettel der Community und ich habe keinen Zweifel daran, dass einige der darauf stehenden Dinge implementiert werden, auch wenn natürlich noch nichts in Stein gemeißelt ist. Ich kann aber mit Sicherheit sagen, dass Dinge wie CDI-Anpassungen, Modularität und die Unterstützung reaktiver Streams sehr populär sind. Auch eine weitreichendere Unterstützung für Microservices und Kubernetes-native Deployments sind wahrscheinlich.

JAXenter: Es gibt einen neuen Prozess für die Determinierung neuer Spezifikationen für Jakarta EE, der den Java Community Process ersetzt. Wie genau unterscheidet sich neue Prozess vom JCP, den wir alle kennen und nicht besonders gut leiden können?

Mike Milinkovich: Die Jakarta-EE-8-Spezifikationen wurden gemäß des Jakarta EE Specification Process und dem Eclipse Development Process entwickelt, die offene und von der Community getriebene Prozesse sind, die den JCP für Java EE ersetzen.

Der Jakarta EE Specification Process ist ein einheitliches Gebilde, bei dem alle Parteien gleich sind und die Zusammenarbeit ein Muss ist.

Ich denke, dass das Wegfallen von Spec Leads, die besondere Rechte in Bezug auf das geistige Eigentum im JCP hatten, den größten Unterschied darstellt. Historisch gesehen haben die Spec Leads eine extrem große Kontrolle über den Output einer Expertengruppe der jeweiligen Spezifikation ausgeübt. Der Jakarta EE Specification Process ist ein einheitliches Gebilde, bei dem alle Parteien gleich sind und die Zusammenarbeit ein Muss ist.

Auch der Code-First-Ansatz des neuen Prozesses stellt einen grundlegenden Unterschied zum JCP und dessen spezifikationszentrischen Ansatz dar. In Bezug auf Spezifikationen selbst kann man eine vollständig offene, kollaborative Herangehensweise für die Erschaffung von Spezifikationen erwarten: Jede Entscheidung wird gemeinsam von der Community getroffen. Das bedeutet auch, dass die gesamte Dokumentation für die Spezifikationen und die TCKs auf dem Open-Source-Modell basieren wird, also von der Community verantwortet und generiert werden.

Die Referenzimplementierungen werden ebenfalls wegfallen und durch mehrere kompatible Produktimplementierungen ersetzt werden. Hinzu kommt ein Prozess der Selbstzertifizierung, der an die Stelle der Zertifizierung durch eine einzelne Organisation tritt.

JAXenter: Ein weiterer Punkt, der noch nicht abschließend definiert ist, ist der Release-Plan für die nächsten Versionen von Jakarta EE. Wird es regelmäßige Releases geben, wie bei Java (SE) oder wird es eher nach dem alten Credo ablaufen “Es ist fertig, wenn es fertig ist”?

Mike Milinkovich: Als Community arbeiten wir gerade noch an den Release-Zyklen selbst, sodass wir uns noch nicht auf eine gewisse Kadenz einigen konnten. Allerdings, soviel kann ich bereits sagen, stehen alle Beteiligten dahinter, Innovationen deutlich schneller als in der Vergangenheit voranzutreiben. Wir müssen, das ist offensichtlich, eine Balance zwischen Faktoren wie Stabilität und Innovation finden. Aber dass diese Dinge von einer vielfältigen Community von Anbietern, Entwicklern und Unternehmen in offener und integrativer Art und Weise diskutiert werden, wird Jakarta EE zum Erfolg verhelfen.

Wie du ja weißt, hat die Eclipse Community Erfahrung damit, große, komplexe Software-Releases termingetreu auf den Tag genau zu liefern – das machen wir seit 15 Jahren. Letztes Jahr haben wir auf vierteljährliche Releases der Eclipse IDE umgestellt und durch die Reife unserer Prozesse und die Mitglieder der Community haben dennoch wie gewohnt geliefert. Mit anderen Worten: Egal, welche Release-Kadenz die Community von Jakarta EE anstreben wird, die Eclipse Community und die Mitarbeiter der Foundation sind bestens darauf vorbereitet.

JAXenter: Was steht für den Rest des Jahres 2019 nun noch auf der Agenda?

Mike Milinkovich: Wir werden definitiv mit der Planung von Jakarta EE 9 beginnen. Außerdem werden wir der gesamten Community dabei behilflich sein, die neuen Prozesse vollständig zu verinnerlichen. Das allein sollte uns dieses Jahr noch gut beschäftigt halten. Es lohnt sich aber, auf dem Laufenden zu bleiben: Es gibt noch viel zu klären bis zum Jahresende.

JAXenter: Vielen Dank für das Interview, Mike!

Mike Milinkovich has been involved in the software industry for over thirty years, doing everything from software engineering, to product management to IP licensing. He has been the Executive Director of the Eclipse Foundation since 2004. In that role he is responsible for supporting both the Eclipse open-source community and its commercial ecosystem. Prior to joining Eclipse, Mike was a vice president in Oracle’s development group. Other stops along the way include WebGain, The Object People, IBM, Object Technology International (OTI) and Nortel. Mike sits on the Executive Committee of the Java Community Process (JCP), and is a past member of the Boards of the Open Source Initiative (OSI), and the OpenJDK community.
Geschrieben von
Dominik Mohilo
Dominik Mohilo
Dominik Mohilo studierte Germanistik und Soziologie an der Goethe-Universität in Frankfurt. Seit 2015 ist er Redakteur bei S&S-Media.
Kommentare

Hinterlasse einen Kommentar

1 Kommentar auf "Jakarta EE 8: „Die Community hat nun endlich eine Open-Source-Grundlage, auf der die Zukunft von Enterprise Java aufgebaut werden kann“"

avatar
4000
  Subscribe  
Benachrichtige mich zu: