Suche
Nomen est Omen...oder so

Java 10 – Jetzt also doch?!

Dominik Mohilo

© shutterstock.com / Vladimirkarp

Eine Patentlösung wird es in der andauernden Diskussion um die jeweiligen Namen zukünftiger Java Releases wohl nicht geben, irgendwer ist immer unzufrieden. Dennoch scheint es so, als wolle Oracle nun doch grob das aktuelle Namensschema beibehalten. Wird also die nächste Version, die bereits für März 2018 geplant ist, Java 10 heißen? Wir haben uns den aktuellen Stand der Dinge einmal angesehen.

Kurz vor der Veröffentlichung von Java 9 schlug Oracle vor, Java ab Version 10 zwei Mal jährlich mit einem Update zu versehen. Damit sollte eines der Kernprobleme angegangen werden, dass Java von anderen Programmiersprachen deutlich unterscheidet. Teils bis zu drei Jahre mussten Java-Entwickler in der Vergangenheit auf neue große Features, wie zuletzt auf Project Jigsaw und die damit verbundene Modularisierung von Java ab Version 9, warten.

In retrospect, a two-year release cadence is simply too slow. To achieve a constant cadence we must ship feature releases at a more rapid rate. Deferring a feature from one release to the next should be a tactical decision with minor inconveniences rather than a strategic decision with major consequences. That’s fast enough to minimize the pain of waiting for the next train yet slow enough that we can still deliver each release at a high level of quality, preserving Java’s key long-term values of compatibility, reliability, and thoughtful evolution.

–Mark Reinhold

Mark Reinholds Vorschlag sieht vor, dass jeweils im März und September jedes Jahres ab 2018 ein sogenanntes Feature Release für Java veröffentlicht wird. Diese können neue neue Sprach- und JVM-Features enthalten, aber auch, wie es bereits bei derzeitigen Java-Updates zwischen den Majors möglich ist, verbesserte APIs. Auf jedes Feature Release sollen zwei Update Releases folgen, diese würden im April und Juli für das erste Feature Release sowie im Oktober und Januar für das zweite Feature Release folgen. Pro Jahr gäbe es also insgesamt sechs neue Java-Versionen.

Außerdem wäre das spätere Update in 2018, sollte Reinholds Plan umgesetzt werden, ein Release mit Langzeitunterstützung, alle drei Jahre (also 2021, 2024 usw.) würde ein weiteres sogenanntes LTS-Update folgen. Für diese Versionen sollen über die gesamte Lebensspanne Updates verfügbar sein.

Java, dein Name sei…

Einhergehend mit dem Vorschlag des neuen Release-Schemas kam die Frage auf, wie man diese ganzen Versionen nun eigentlich bezeichnen soll. Mark Reinhold schlug vor, dass man auf ein Namensschema im Stile von $YEAR.$MONTH setzen wolle. Java 10 würde dann also stattdessen Java 18.3 heißen, Java 18.9 wäre der Name des ersten Releases mit Langzeitsupport.

Überraschend ist keinesfalls, dass dies in der Community nicht unbedingt auf Gegenliebe stieß. Java hat traditionell „ganze Zahlen“ als Versionsnummern und ein Bruch damit bereitet einigen Bauchschmerzen, unter anderem Stephen Colebourne, der seine Bedenken in der JDK Mailing-Liste anbrachte. Daraufhin bot Mark Reinhold drei Alternativen an:

(A) (B) (C)
GA (März 2018) 1803 18.3 10
Update Release 1 (April) 1803.1 18.3.1 10.1
Update Release 2 (Juli) 1803.4 18.3.4 10.1
GA (September 2018) 1809 18.9 11
Update Release 1 (Oktober) 1809.1 18.9.1 11.1
Update Release 2 (Januar) 1809.4 18.9.4 11.4

Version (A) würde sich dabei auf Jahr und Monat und das Alter des Updates beziehen, also ein Monat nach Veröffentlichung bzw. vier Monate nach Veröffentlichung des entsprechenden Major Releases ($YY$MM.$AGE). Version (B) basiert der von Reinhold ursprünglich vorgeschlagenen Benennung $YY$M.$AGE, bei der sich die letzte Zahl ebenfalls auf die Anzahl der Monate bezieht, seit das entsprechende Major Release veröffentlicht wurde. Die dritte Alternative führt die laufende Versionsnummerierung nach dem Schema $N.$AGE weiter.

Java 10 – nun also doch?

Vor knapp einer Woche veröffentlichte Mark Reinhold nun ein weiteres Konzept, das dem derzeitigen Namensschema von Java (definiert im JEP 223) noch mehr entspricht als Version (C) seines vorherigen Proposals, ist aber gleichwohl deutlich komplizierter aufzudröseln.

Die Versionsnummer $VNUM soll sich aus einer Sequenz von Ziffern zusammensetzen, die jeweils durch Punkte voneinander getrennt sind: $FEATURE.$INTERIM.$UPDATE.$EMERG

  • $FEATURE – Dies ist die geplante Versionsnummer des Major Releases, also konkret für März 2018 wäre das die 10, für September die 11 usw. (Vorher: $MAJOR)
  • $INTERIM – Dieser Wert soll für das geplante Modell immer 0 sein, um für die Zukunft flexibel zu sein, sollte sich etwas am Veröffentlichungszyklus etwas ändern. (Vorher: $MINOR)
  • $UPDATE – Dies ist die geplante Nummer des Updates des Major Releases, für das Update im April 2018 wäre die Nummer 1 (Java 10.0.1) reserviert, für Juli die Nummer 2 (Java 10.0.2) usw. (Vorher: $SECURITY)
  • $EMERG – Dieser Wert ist wie $INTERIM zur reinen Sicherheit an dieser Stelle und soll nur genutzt werden, wenn ein schwerwiegendes und dringendes Sicherheitsproblem ein Update unabdingbar macht.

We do expect most feature releases to contain at least one or two significant features, and never to ship interim releases under the new release model, so in practice this scheme will often be very similar to a compatibility- or significance-oriented scheme like that of JEP 223. JDK 10 is a feature release, JDK 10.0.1 and 10.0.2 are update releases with compatible bug fixes, and there is no interim JDK 10.1 release since in this model the next opportunity to add features is JDK 11.

–Mark Reinhold

Ob sich dieses Schema und der Veröffentlichungsrhythmus durchsetzen kann und auch in der tatsächlichen Anwendung praktikabel ist, steht allerdings noch in den Sternen. Es gibt auch hierzu bereits Bedenken. Allerdings ist offensichtlich, dass Oracle und insbesondere Mark Reinhold den Wunsch der User berücksichtigen wollen, keine Jahreszahl als Versionsnummer aufgezwungen zu bekommen. Java 10 liest sich eben doch einfach schöner als Java 18.3, oder nicht?

Achtung! Endgültig geklärt ist, was die Versionsnummern angeht, allerdings weiterhin noch nichts. Die Vorschläge von Mark Reinhold sind, auch wenn er ein offizieller Vertreter von Oracle ist und als solcher in den Mailing-Listen auch agiert, nichts weiter als eben das: Vorschläge. Wie die endgültige Entscheidung allerdings aussehen wird, sollte in naher Zukunft entschieden werden, denn die erste Rampdown-Phase soll schon bald beginnen.

Weitere Informationen zum jüngsten Proposal von Mark Reinhold gibt es auf der JDK Mailing-Liste.

Verwandte Themen:

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

Schreibe einen Kommentar

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