Suche
Auf dem Weg zum agilen Java-Standard?

Java-Versionen sollen häufiger erscheinen: Oracle plant neue Release-Politik

Hartmut Schlosser

© Shutterstock.com/pattara puttiwong

Oracle plant, neue Java-Versionen häufiger bereit zu stellen. Statt der großen Java-SE-Releases, die im 2- bis 3-Jahresrhythmus erscheinen, soll es Zwischenreleases geben. Noch unklar ist, wie ein solches agiles Vorgehen innerhalb des JCP (Java Community Process) abgebildet werden kann.

Das jahrelange Warten auf die neuen Features der nächsten großen Java-Version ist nicht mehr zeitgemäß. So lautete bereits das Fazit des letzten Face-to-Face-Meetings des Java SE Exekutiv-Komitees (November 2016). Georges Saab (Oracle) brachte stattdessen das Modell eines Release-Zuges ins Spiel, bei dem neue Java-Versionen nach einem festen Zeitplan veröffentlicht würden und dann genau die Features enthielten, die zu diesem Zeitpunkt fertig seien.

Der Vorteil: Release-Verschiebungen aufgrund einer geplanten aber noch nicht rechtzeitig finalisierten Neuerung würden somit der Vergangenheit angehören. Etwa würde beim aktuellen Java 9 das aufwändige Jigsaw-Projekt, das bereits für etliche Verschiebungen gesorgt hat, nicht mehr kleinere, bereits fertiggestellte Verbesserungen blockieren.

„Unser Durchsatz ist gut, aber unsere Latenzzeit nicht“, lautete Saabs Fazit, in dem er als Ziel ein agileres Vorgehen bei der Standardisierung von Java ausgab.

Kein Warten mehr auf JEPs

Wie das langjährige JCP-Mitglied Simon Ritter (Azul Systems) nun berichtet, wurden diese Pläne im aktuellen Meeting des Exekutiv-Komitees konkretisiert. So besteht die Idee darin, nach der Veröffentlichung von Java SE 9 (27 Juli 2017) die wohlbekannten JEPs (Java Enhancement Proposals) nicht mehr bis zum Java-10-Release zurückzuhalten. JEPs würden isoliert voneinander entwickelt und nach Fertigstellung ins JDK integriert. Statt also monate- bzw. jahrelang auf die große Java-Major-Version zu warten, um in den Genuß der Neuerungen zu kommen, könnte man bereits in einer Zwischenversion wie Java 9.1.13 auf diese zugreifen.

So weit, so gut, das findet auch Simon Ritter. Doch gleichzeitig gibt er zu bedenken, dass eine solche feingranulare Release-Politik einige Fragen aufwirft. Zunächst führt es zu einer Art Fragmentierung der Java-Versionen, auf die sich Entwickler einstellen müssten. Denn jeder Java SE Code bzw. die Binaries eines jeden Java-Zwischenreleases benötigen auch das jeweils zugehörige JDK/JRE.

Noch schwieriger sieht Ritter die Situation in Bezug auf die existierenden JCP-Prozesse: Jede kleine Neuerung (JEPs) müsste formal einem JSR zugeordnet und durch eine Experten-Gruppe, eine Public Review und Experten-Abstimmung geschleust werden. Angesichts der 90 JEPs, die bereits in JDK 9 aufgenommen wurden, sei das nicht mehr handhabbar.

Für Ritter steht fest: Auf dem Weg zu einem wirklich agilen Java-Standard, braucht es auch weitreichende Veränderungen der JCP-Prozesse.

It seems to me that the JCP will require some substantial changes to the processes it uses (at least for Java SE, but possibly the same approach will be utilised for Java EE) for this to work practically. Let’s hope that it is indeed possible to make an agile Java standard.

Der Hinweis auf Java EE ist interessant. Gerade in den letzten Monaten hatten Kritiker auch dem Java-Enterprise-Standard ein zu schwerfälliges Fortschreiten vorgeworfen und dabei auf die dynamischeren Prozesse etwa bei Spring oder der Microprofile-Initiative verwiesen. Der weitere Fortgang der Debatte wird also mit Spannung zu verfolgen sein.

Verwandte Themen:

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Hartmut Schlosser ist Redakteur und Online-Koordinator bei Software & Support Media. Seine Spezialgebiete liegen bei Java-Enterprise-Technologien, JavaFX, Eclipse und DevOps. Vor seiner Tätigkeit bei S & S Media studierte er Musik, Informatik, französische Philologie und Ethnologie.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.