Der neue Releasezyklus von Java

Inhaltsverzeichnis

Wenn man den bekannten Spielentwickler John Carmack fragte, wann das nächste Doom erscheint, antwortete er üblicherweise "When it's done". Früher lief es in Java ähnlich. Java 7 zum Beispiel erschien im Juli 2011 nach viereinhalb Jahren Entwicklung.

Im Jahr 2012, die JDK-Entwickler arbeiteten gerade fieberhaft am Release von Java 8, kamen Zweifel daran auf, ob ein Feature-getriebener Release-Zyklus sinnvoll sei. Mark Reinhold, Chief Architect der Java Platform Group bei Oracle, sprach sich damals für einen rein zeitbasierten Releasezyklus aus. Alle zwei Jahre sollte eine neue Java-Version herauskommen. Mit allen Features, die dann fertig sein werden – die, die es nicht rechtzeitig geschafft hätten, müssten auf die nächste Version warten.

Das hat, vorsichtig ausgedrückt, nicht gut funktioniert. Java 8 verzögerte sich wieder und wieder und erschien im März 2014 nach beinahe drei Jahren Entwicklungszeit, Java 9 im September 2017 nach dreieinhalb. Das ist ärgerlich für alle Beteiligten: Die JDK-Entwickler geraten unter Druck, Features rechtzeitig fertigzustellen, und der Rest der Community ist enttäuscht, dass es länger und länger dauert, bis sie neue Werkzeuge bekommt. In der Zwischenzeit lungern fertiggestellte Features im Repository der unveröffentlichten Version herum und schaffen keinen Mehrwert.

Aber warum haben die Entwickler das Zweijahresziel so klar verpasst? Treibende Kraft war die wiederkehrende Fehleinschätzung, dass ein Feature fast fertig war und unbedingt noch in die neue Version musste (in Java 9 war es zum Beispiel das Modulsystem). Aber "fast fertig" ist in der Softwareentwicklung ein dehnbarer Begriff.

"The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time." (Tom Cargill, Bell Labs)

Das Problem ist weniger das Verschieben auf die nächste Version, als dass die zwei (oder mehr) Jahre bis dahin eine lange Zeit sind. Je kürzer der Abstand zwischen Releases, desto einfacher ist es für die Entwickler eines Features, ein Release zu verpassen und das nächste anzupeilen. Zwei Jahre ist dafür auf jeden Fall zu lang, ein Jahr scheint ziemlich genau auf der Kippe zu stehen, aber sechs Monate sind deutlich diesseits der Schwelle. Da sorgt es nicht einmal bei den ungeduldigsten Entwicklern für Missmut, wenn ein Feature in einer späteren Version landet.

Gut Ding will Eile haben

Jetzt erscheint alle sechs Monate eine neue Java-Version. Dabei hat jedes Release die gewohnte Qualität – es gibt keine Beta-Versionen. Dass Oracle und andere Anbieter für manche Versionen Long-Term-Support anbieten, ist eine organisatorische Entscheidung, keine technische: LTS-Versionen unterscheiden sich hinsichtlich der eingebrachten Sorgfalt und der Qualitätsansprüche nicht ein Jota von den anderen Versionen.

Der schnellere Releasezyklus hat eine Reihe positiver Effekte:

• Features entstehen ohne Zeitdruck und ohne dadurch fertiggestellte Funktionen zu blockieren.
• Features stehen zwischen drei und neun Monate nach ihrer Fertigstellung zur Verfügung.
• Entwickler können neue Features zunächst als Preview vorstellen und über ein oder zwei Versionen hinweg verfeinern.
• Mit Incubator Modules und Preview Features stehen zwei Mechanismen bereit, Neues auszuprobieren, ohne Kompatibilitätsproblemen den Weg zu ebnen.
• Java kann schneller auf Entwicklungen im Ökosystem reagieren.

Aber nichts ist umsonst und die Softwareentwicklung ist voller Trade-offs. Es gibt teilweise berechtigte Sorgen, dass der schnelle Zyklus ernsthaften Nachteil mitbringt:

• Java verändert sich zu schnell.
• Ständige Migrationen sind aufwendig.
• Die Testmatrix explodiert.
• Das Ökosystem ist fragmentiert.

Der Rest des Artikels beleuchtet die Sorgen genauer und prüft, an welchen etwas dran ist und was man getrost auf sich zukommen lassen kann. Spoiler: Ganz so dramatisch wird es wohl nicht.