Suche
JEP 322 definiert neues Versionsschema für Java

Next stop Java 10: Roadmap für neue Java-Versionen steht fest

Hartmut Schlosser

© Shutterstock / Milan M

Java 10,11,12… und nicht Java 2018.3, 2018.9, 2019.3… So die Kurzfassung der Entscheidung über das Namensschema, das Oracle für die nächsten Java-Versionen vorgesehen hat. Doch wie so oft steckt im Namen viel mehr, als zunächst vermutet…

Wir erinnern uns: Im September hatte Oracle entschieden, Java-Releases in Zukunft in einem 6-Monats-Rhythmus zu veröffentlichen. Diese sogenannten Feature-Releases sollen jeweils im März und September eines Jahres erscheinen und neue Sprach- sowie JVM-Features enthalten können.

Zwischen diesen Feature-Releases sind zwei Updates geplant, bei denen es um Maintenance und Bugfixing gehen soll – im April, Juli bzw. Oktober, Januar des Jahres. Außerdem wird alle drei Jahre eines der Feature-Releases zum Longterm-Support-(LTS)-Release erklärt – als erstes die September-Version 2018, für die während ihrer gesamten Lebensspanne Updates zur Verfügung gestellt werden sollen.

So weit, so gut. Wurde dieser Plan in der Community allenthalben begrüßt, so gab es doch Dissens über das neue Versionierungsschema. Der ursprüngliche Vorschlag, die Versionen nach Jahr und Datum des Erscheinens zu benennen, war auf wenig Gegenliebe gestoßen: Java 2018.3 für das März-Release, 2018.9 für das September-Release mit den entsprechenden Ableitungen für die Updates: 2018.3.1, 2018.3.2, etc.

Nach ausgiebigen Diskussionen hatte Mark Reinhold einen Vorschlag auf der Mailing-Liste verbreitet, der wieder in die Richtung Java 10,11,12 wies – und der wiederum reichlich in der Community diskutiert wurde. Auf Basis dieser eloquenten Feedback-Zyklen hat Reinhold nun einen offiziellen JEP (Java Enhancement Proposal) eingereicht, der mit hoher Wahrscheinlichkeit das Endergebnis darstellen wird: JEP 322: Time-Based Release Versioning.

JEP 322: Time-Based Release Versioning

Zusammengefasst bestehen die neuen Versionszahlen aus vier Elementen: $FEATURE.$INTERIM.$UPDATE.$PATCH

  • $FEATURE — Der Feature-Release-Zähler wird für jedes Feature-Release um eins nach oben gesetzt. Neue Features können hier hinzukommen – aber auch entfernt werden, wenn dies mindestens ein Feature-Release vorher angekündigt wurde. Demnach wird die nächste Java-Version im März 2018 den Namen Java 10 tragen.
  • $INTERIM — Der Interim-Release-Counter zählt etwaige Minor-Versionen zwischen den Feature-Releases. In diesen Zwischenversionen sind kompatible Bugfixes und Verbesserungen möglich, jedoch keine inkompatiblen Veränderungen, Feature-Entfernungen oder API-Anpassungen.
  • $UPDATE — Der Update-Release-Zähler ist für kompatible Updates vorgesehen, in denen Sicherheitsprobleme und Bugs in neuen Features gefixt werden.
  • $PATCH — Der sogenannte „Emergency Patch-Release-Zähler“ zeigt an, dass in der Version ein kritisches Problem behoben wurde. Diese vierte Stelle im Versionsschema ist neu und soll das spontane Einschieben von Sicherheitsupdates erleichtern.

Versionen können auch weitere Nachkommastellen enthalten. Diese sind allerdings für Nutzer der JDK-Codebasis vorgesehen, um etwa implementierungsspezifische Patch-Releases anzuzeigen.

Wie die nächsten Java-Versionen heißen

In einem 6-monatigen Release-Rhythmus bedeutet das nun konkret, dass der Zähler $FEATURE alle 6 Monate erhöht wird:

  • Java 10 – März 2018
  • Java 11 – September 2018
  • Java 12 – März 2019
  • Java 13 – September 2019

Der $INTERIM-Zähler wird im vorgesehenen Modell nicht benötigt ist bleibt im Normalfall 0. Eingeführt wird er nur, um in einem zukünftigen Release-Modell Interim-Versionen zu ermöglichen, wie das zum Beispiel bei JDK 1.4.1 und JDK 1.4.2 der Fall war.

Der $UPDATE-Zähler wird hingegen für die beiden geplanten Updates zwischen den Feature-Releases genutzt. Diese würden dann so aussehen:

  • Java 10.0.1 – April 2018
  • Java 10.0.2 – Juli 2018
  • Java 11.0.1 – Oktober 2018
  • Java 11.0.2 – Januar 2019

Die Roadmap der kommenden Java-Versionen sieht damit folgendermaßen aus:

 

Java 10 Versionierung

Versionierung der kommenden Java-Releases (zum Vergrößern anklicken). Grafik erstellt von Wolfgang Weigend (Oracle)

Erwartet wird, dass jedes Feature-Release mindestens ein oder zwei signifikante neue Features enthalten wird. Update-Releases sollen hingegen keine Inkompatibilitäten nach sich ziehen. In der Praxis soll dieses Schema damit so nahe wie möglich am bisherigen Modell, beschrieben in JEP 223, bleiben.

Are we final?

Der neue JEP 322 wurde von Mark Reinhold eingereicht und von Alan Bateman, Alex Buckley, Dalibor Topic, Iris Clark und John Rose begutachtet. Laut eigenen Angaben ist der Vorschlag das Ergebis eines langen Feedback-Prozesses:

The proposal for the six-month time-based release model suggested that the version strings of feature releases be of the form $YEAR.$MONTH. Thus next year’s March release would be 18.3, the September release would be 18.9, and so on each year.

After reasonable objections were raised against this scheme we reviewed the various types of information encoded in version numbers and suggested some alternatives, then summarized and responded to the discussion that followed, and finally published a proposal that was well received and hence became the basis for this JEP.

Der JEP 322 ist seit dem 4. Dezember nicht mehr nur ein „JEP draft“ sondern hat bereits den Status „Candidate“. Zur endgültigen Verabschiedung fehlt lediglich der finale Status „Closed / Delivered“, der im JDK Bug-System im Issue JDK-8192828 bearbeitet wird. Eine Lösung dieses Issues dürfte in Kürze bevor stehen.

LESEN SIE AUCH:

Expertencheck: Welche neuen Features erwarten uns in Java 10?

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
  1. Peter2017-12-06 11:09:42

    Also ich bin bei Java releases (noch) sehr konservativ eingestellt. Deshalb würde ich begrüssen, dass im Version string ein LTS für eben diese Version stehen würde. Sonst muss man wohl häufiger nachschlagen, bei einem simplen "java -version, welche jetzt die LTS Version ist .

    Ah ja, seher gerade in der JEP322 das dies der Fall sein wird. Vieleicht gut zu wissen, für de Konservativen unter uns ;-)

  2. Hartmut Schlosser2017-12-06 14:06:22

    Hallo Peter - vielen Dank für diese Ergänzung. In JEP 322 heißt es dazu:

    "The overall format of version strings is the same as that defined in JEP 223. A version string is a version number, $VNUM, possibly followed by pre-release, build, and other optional information, one of:

    $VNUM(-$PRE)?\+$BUILD(-$OPT)?
    $VNUM-$PRE(-$OPT)?
    $VNUM(+-$OPT)?

    where $PRE is a pre-release identifier (e.g., ea), $BUILD is a build number, and $OPT is optional build information.

    If a release is part of a series of releases for which an implementor offers long-term support then the value of $OPT should start with "LTS", e.g., 11.0.2+13-LTS. This will cause "LTS" to be displayed prominently in the output of java --version, etc., more on which below."

Schreibe einen Kommentar

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