Der neue Java-Releasezyklus

Rate this post

Nachdem Oracle den neuen Release-Zyklus für Java eingeführt hatte, war ich von dieser Strategie nicht überzeugt. Auch heute noch bin ich anderer Meinung. Ein Kritikpunkt ist die Vernachlässigung der semantischen Versionierung. Auch die Behauptung, der neue Zyklus ermögliche eine schnellere Bereitstellung neuer Funktionen, teile ich nicht. Meiner Ansicht nach könnten dadurch zukünftig Probleme auftreten. Doch Moment, fangen wir von vorne an, bevor ich meine Gedanken ausführlich darlege.

Der von Oracle 2017 angekündigte sechsmonatige Release-Zyklus für Java sorgte für Unsicherheit in der Community. Die größte Befürchtung wurde durch die weit verbreitete Frage formuliert: Wird Java in Zukunft nicht mehr kostenlos sein? Die Antwort ist natürlich ein klares Nein, aber Unternehmen sollten sich der Auswirkungen bewusst sein. Bei großen Produktionsanwendungen ergeben sich einige Punkte für das Risikomanagement und die Geschäftskontinuitätsstrategie. Wenn der LTS-Support für Sicherheitsupdates nach dem dritten Jahr einer veröffentlichten Version kostenpflichtig wird, sind klar definierte Update-Strategien für den Produktiveinsatz unerlässlich. Ich befürchte, zukünftig mehr Zeit mit der Migration meiner Projekte auf neue Java-Versionen verbringen zu müssen als mit der Implementierung neuer Funktionen. Eine Lösung, um ständige Update-Orgien zu vermeiden, wäre der Wechsel von der Oracle JVM zu OpenJDK.

Im professionellen Umfeld ist es üblich, dass Unternehmen aus Sicherheitsgründen ein festes Setup definieren. Wenn ich jedoch ständig gezwungen bin, meine Komponenten zu aktualisieren, ohne die Sicherheit der neuen Funktionen zu gewährleisten, kann das Probleme verursachen. Kommerzielle Projekte laufen unter anderen Bedingungen und benötigen oft besondere Aufmerksamkeit. Denn man braucht eine klar definierte Umgebung, in der alles stabil läuft. Es gilt: Niemals ein laufendes System anfassen.

Ich kann Oracles Intention hinter diesem Schritt durchaus nachvollziehen. Ich vermute, es ist ein Weg, alte, fehlerhafte und unsichere Installationen loszuwerden und das Internet sicherer zu machen. Natürlich kann man keine jahrzehntealten, veralteten Versionen mehr unterstützen. Das hätte erhebliche finanzielle Auswirkungen. Ich wünschte mir jedoch eine weniger rabiate Strategie. Leider ist es in der Geschäftswelt oft üblich, so zu agieren. Ich wünschte, es gäbe eine vertrauensvollere Kommunikation.

Erfahrungsgemäß dauert es bei Java-Vorabversionen immer eine Weile, bis sie stabil laufen. In diesem Zusammenhang erinnere ich mich an einige gravierende Probleme, die ich mit der Umstellung auf 64-Bit-Versionen hatte. Das gängige Motto „Das Neueste ist das Beste“ kann gefährlich sein. Insbesondere zeitbasierte Releases bergen ein hohes Risiko für Probleme, selbst bei erfahrenen Teams. Der Druck, pünktlich zu liefern, ist enorm.

Ein weiterer Diskussionspunkt ist die semantische Versionierung. Es ist ein sehr wirkungsvolles Verfahren, das ich stets empfehle. Ich frage mich jedoch, ob es wirklich alle sechs Monate neue Sprachfunktionen gibt, die eine Erhöhung der Major-Versionsnummer rechtfertigen? Selbst bei Patches und Erweiterungen? Was aber passiert, wenn zukünftig keine neuen Sprachfunktionen mehr benötigt werden? Das erzwungene Hinzufügen neuer Funktionen kann die Qualität beeinträchtigen. Meiner Meinung nach enthält Java viele lehrreiche Funktionen, und nicht jede neue Funktion erweitert den Funktionsumfang der Sprache. Ein einfaches Beispiel ist die bekannte GOTO-Anweisung in anderen Sprachen. Programmieranfänger haben oft gelernt: „Wenn du etwas siehst, lauf weg. Benutze niemals GOTO.“ In Java vergleiche ich innere Klassen oft mit GOTO, da ich denke, dass man dies vermeiden sollte. Bisher habe ich keinen Fall gefunden, in dem innere Klassen nicht auf Designprobleme hindeuten. Dasselbe gilt für die häufige Verwendung von Funktionsanweisungen. Ich sehe keinen Vorteil darin, eine for-Schleife als Lambda-Funktion anstatt auf die klassische Weise zu definieren.

Meiner Meinung nach versucht Oracle hier, sich ein Stück vom Kuchen zu sichern, um das eigene Geschäft auszubauen. Das ist an sich nicht schlecht. Aus Sicht des Projektmanagements halte ich diese Strategie jedoch für fragwürdig.

Weiterlesen: https://www.infoq.com/news/2017/09/Java6Month/