Zeitbasierte Releases von Java

1. Einleitung

In diesem Artikel werden die neuen zeitbasierten Versionen von Java und die Auswirkungen auf alle Arten von Entwicklern erläutert.

Zu den Änderungen am Release-Zeitplan gehört die Aktualisierung der Funktionsbereitstellung und der Support-Levels für Java-Versionen. Insgesamt unterscheiden sich diese Änderungen deutlich von Java, das seit 2010 von Oracle unterstützt wird.

2. Warum sechsmonatige Veröffentlichungen?

Für diejenigen von uns, die an Javas historisch langsame Release-Trittfrequenz gewöhnt sind, ist dies eine ziemlich bedeutende Abweichung. Warum so eine dramatische Veränderung?

Ursprünglich definierte Java seine Hauptversionen um die Einführung großer Funktionen. Dies hatte die Tendenz, Verzögerungen zu verursachen, wie wir sie alle mit Java 8 und 9 erlebt haben. Es verlangsamte auch die Sprachinnovation, während sich andere Sprachen mit engeren Feedback-Zyklen entwickelten.

Einfach ausgedrückt führen kürzere Veröffentlichungszeiten zu kleineren, überschaubareren Schritten nach vorne. Und kleinere Funktionen sind einfacher zu übernehmen.

Ein solches Muster passt unter den gegenwärtigen Bedingungen gut zusammen und ermöglicht es der JDK-Entwicklung, in agilen Methoden zu arbeiten, die der von ihr unterstützten Community ähneln. Außerdem macht es Java wettbewerbsfähiger mit Laufzeiten wie NodeJS und Python.

Natürlich hat das langsamere Tempo auch seine Vorteile, und so spielt der sechsmonatige Veröffentlichungszyklus auch eine Rolle in einem größeren Rahmen für den langfristigen Support, den wir in Abschnitt 4 betrachten.

3. Änderung der Versionsnummer

Ein mechanischer Aspekt dieser Änderung ist ein neues Versionsnummernschema.

3.1. JEP 223 Version-String-Schema

Wir alle kennen die alte, die in JEP 223 kodifiziert ist. Durch dieses Schema wurden die Versionsnummern inkrementell und zusätzliche Informationen weitergeleitet.

 Actual Hypothetical Release Type long short ------------ ------------------------ Security 2013/06 1.7.0_25-b15 7u25 Minor 2013/09 1.7.0_40-b43 7u40 Security 2013/10 1.7.0_45-b18 7u45 Security 2014/01 1.7.0_51-b13 7u51 Minor 2014/05 1.7.0_60-b19 7u60

Wenn wir Java-Version auf einer JVM für Version 8 oder älter ausführen, sehen wir Folgendes :

>java -version java version "1.6.0_27" Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0_27-b07) Java HotSpot(TM) Client VM (build 1.6.0_27-b13, mixed mode, sharing)

In diesem Fall könnten wir vermuten, dass dies für Java 6 ist, was korrekt ist, und für das 27. Update, was falsch ist. Das Nummerierungsschema ist nicht so intuitiv wie es scheint.

Kleinere Releases waren ein Vielfaches von 10, und Sicherheits-Releases füllten alles andere. In der Regel wird die kurze Zeichenfolge an unsere lokalen Installationen angehängt, z. B. JDK 1.8u174. Die nächste Version könnte JDK 1.8u180 sein, eine kleinere Version mit neuen Korrekturen.

3.2. Neues Version-String-Schema

Das neue Versionszeichenfolgenschema wird "die Versionsnummern neu formulieren, um nicht die Kompatibilität und Bedeutung, sondern den Zeitablauf in Bezug auf die Veröffentlichungszyklen zu kodieren ", so Mark Reinhold im JEP.

Schauen wir uns einige an:

9.0.4 11.0.2 10.0.1

Auf den ersten Blick scheint dies eine semantische Versionierung zu sein. Dies ist jedoch nicht der Fall.

Bei der semantischen Versionierung lautet die typische Struktur $ MAJOR. $ MINOR. $ PATCH , aber die neue Versionsstruktur von Java lautet:

$FEATURE.$INTERIM.$UPDATE.$PATCH

$ FEATURE ist das, was wir als Hauptversion betrachten , wird jedoch unabhängig von den Kompatibilitätsgarantien alle sechs Monate erhöht. Und $ PATCH ist für Wartungsversionen. Aber hier hören die Ähnlichkeiten auf.

Erstens ist $ INTERIM ein Platzhalter, der von Oracle für zukünftige Anforderungen reserviert wird. Vorerst wird es immer Null sein.

Und zweitens ist $ UPDATE zeitbasiert wie $ FEATURE und wird monatlich nach der neuesten Feature-Version aktualisiert .

Und schließlich werden nachgestellte Nullen abgeschnitten.

Dies bedeutet, dass 11 die Versionsnummer für Java 11 ist, die im September 2018 veröffentlicht wurde, 11.0.1 die erste monatliche Update-Version im Oktober ist und 11.0.1.3 eine hypothetische dritte Patch-Version aus der Oktober-Version wäre.

4. Mehrere Versionsverteilungen

Schauen wir uns als nächstes an, wie Sie die richtige Version auswählen.

4.1. Stabilität

Einfach ausgedrückt, Java hat jetzt alle sechs Monate einen schnellen Kanal und alle drei Jahre einen langsamen Kanal. Jede Veröffentlichung im dritten Jahr wird als LTS-Veröffentlichung bezeichnet.

Auf dem schnellen Kanal gibt die Sprache Funktionen für die Inkubation frei. Diese Sprachfunktionen stabilisieren sich in der LTS-Version.

Unternehmen, die die Volatilität im Austausch für die Nutzung neuer Funktionen nutzen können, können den schnellen Kanal nutzen. Unternehmen, die Stabilität schätzen und auf ein Upgrade warten können, können bei jeder LTS-Version ein Upgrade durchführen.

Durch Experimentieren mit JDK-Versionen können Entwickler die beste Lösung finden.

4.2. Unterstützung

Es gibt natürlich auch die Frage der Unterstützung. Was tun wir, nachdem die Java 8-Unterstützung den Sonnenuntergang hat?

Wie bereits erwähnt, erfolgt die Antwort in LTS-Versionen, wobei Java 11 die neueste LTS-Version und 17 die nächste ist . Updates werden von Anbietern wie Oracle und Azul verfügbar sein und unterstützt.

Wenn wir der Unterstützung der Community vertrauen können, haben Redhat, IBM und andere ihre Unterstützung für die Anwendung von Fehlerkorrekturen für OpenJDK erklärt. Das AdoptOpenJDK-Projekt bietet außerdem vorgefertigte Binärdateien für OpenJDK.

4.3. Lizenzierung

Ein Bereich der Verwirrung für einige ist der Unterschied zwischen OpenJDK und Oracle JDK.

Tatsächlich sind sie nahezu identisch und unterscheiden sich laut Brian Goetz nur darin, welche Fehlerbehebungen und Sicherheitspatches gefunden wurden.

OpenJDK acts as the source of most derived JDKs and remains free. Starting with Java 11, Oracle will charge commercial license fees for the Oracle JDK with additional support and services included.

4.4. Fragmentation

With more frequent releases, fragmentation may become an issue. Hypothetically, everyone could be running on different versions of Java with different features even more so than now.

Of course, containerization could help address this. From Docker and CoreOS to Red Hat's OpenShift, containerization provides the needed isolation and no longer forces one installation location for Java to be used across the server.

5. Conclusion

Zusammenfassend können wir vom Java-Team von Oracle mit einer regelmäßigen Veröffentlichung von Java alle sechs Monate viel mehr erwarten. Als Java-Entwickler ist die Aussicht auf neue Sprachfunktionen alle sechs Monate aufregend.

Denken wir an einige der Auswirkungen, wenn wir entscheiden, was unser Upgrade-Kanal ist, wenn wir Support und Lizenzierung benötigen und wie wir mit Fragmentierung umgehen sollen.