Sag mal...

Wie läuft das mit dem JDK-Support jetzt gleich noch mal?

Niko Köbler, Carina Schipper

© Shutterstock / Kannika Changsalak

Seit dem 20. März ist Java 10 da, angekommen im Entwickleralltag ist es sicherlich noch nicht. Von der Veröffentlichung einer neuen Version bis zum tatsächlichen Einsatz vergeht schon einmal etwas Zeit. Der ein oder andere dürfte sich sicherlich auch noch vor dem Modulsystem in Java 9 scheuen. Kommt hinzu, dass Release nicht gleich Release ist. Nicht jedes bringt einen Long Term Support mit.

Sag mal…
In der Reihe „Sag mal… mit Carina & Niko“ kommentieren Java-Magazin-Redakteurin Carina Schipper und Software-Architekt Niko Köbler verschiedene Themen aus der Welt der Softwareentwicklung.

Wie läuft das mit dem JDK-Support jetzt gleich noch mal?

Anlässlich der Veröffentlichung von Java 10 wollten wir in der Redaktion wissen, mit welcher Version die Welt da draußen im echten Leben eigentlich so arbeitet. Die Frage verlangt nach einem Quickvote auf JAXenter. Achtung, Achtung! Die kleine Befragung ist genauso ausgefallen, wie wir uns das schon gedacht haben:

Java 8 ist der klare Sieger, was die aktuelle Verbreitung und Nutzung im Alltag angeht | © Software & Support Media

Die Eckdaten: Insgesamt haben rund 1.600 JAXenter-Leser mitgemacht und den Java-Versionen 5, 6, 7, 8 und 9 ihre Stimme gegeben. Ganz oben auf dem Treppchen steht wenig überraschend Java 8 mit 69,97 Prozent. Weit dahinter liegen Java 9 mit (doch) 13,20 Prozent und Java 7 mit (immer noch) 11,33 Prozent. Java 6 erreicht den vorletzten Platz (4,32 Prozent) und Java 5 ist erwartungsgemäß das Schlusslicht (0,56 Prozent). Und Java 10? Ach, lassen wir das. In Sachen Nutzungszahlen ein Urteil abzugeben, ist ohne valide Daten sicherlich schwierig. Einen Blick in die Zukunft wollen wir trotzdem riskieren.

Java 10 hat nicht die Welt verändert, keine Frage. Trotzdem bringt das Release einige nette Features mit. Das wahrscheinlich bedeutendste hört auf den Namen Local-Variable Type Interference (JEP 286). Typinferenz bedeutet, mithilfe der restlichen Angaben des Codes und der Typisierungsregeln auf Datentypen zu schließen. In der Konsequenz lässt sich eine Menge Schreibarbeit vermeiden. Der Quellcode speckt deutlich ab und die Lesbarkeit nimmt zu. Das könnte Ihnen bekannt vorkommen: „Wir kennen das in Java bereits bei Lambdaparametern und beim Diamond-Operator für generische Datencontainer bzw. seit Java 9 auch für anonyme innere Klassen“, schreibt Falk Sippach in seinem Beitrag zu den Java-10-Features.

Mach mal anders – zeitbasiert statt featuregetrieben

Stichwort Java 9 – seit dem Release im September 2017 setzt Oracle auf Jigsaw und stellt die Community damit vor Herausforderungen. Jetzt der nächste Streich: Der Releasezyklus ändert sich. Bisher operierte man bei neuen Java-Versionen featuregetrieben. Damit ist jetzt Schluss: zeitbasiert lautet die neue Devise. Dieses Modell ist durchaus sinnvoll. Schon nach sechs Monaten wird Java 11 Java 10 ablösen. Dazwischen liegen nur zwei kleinere Public Releases. Die Community muss nicht länger auf kleinere Features warten.

Zusätzlich ist Java 10, wie schon Version 9, im Gegensatz zu Java 11 recht kurzlebig. Erst mit Letzterem im September 2018 wird es wieder Long Term Support geben, allerdings nur für zahlende Kunden.

Lesen Sie auch: 11 Expertenmeinungen zu Java 10: Wie steht es mit dem neuen Release-Zyklus und der Legacy?

Service Releases und Patches bekommen Unternehmen nur dann für einen längeren Zeitraum, wenn sie bei Oracle einen Supportvertrag abschließen (Abb. 2). Gerade größere Unternehmen, etwa Banken oder Industriekonzerne, werden den Releasemarathon ohne diesen nicht mitmachen können oder wollen. Oracles Director Java SE Product Management, Sharat Chander, stellt die berechtigte Frage: „When 10 comes out, what happens to 9? It’s no longer supported […] There’s no way for us to keep up with that level of support pace.“

Nach Java 11 wird erst Java 17 2021 wieder ein LTSR sein | Quelle: Azul Systems

Alle sechs Monate eine drei Jahre supportete LTS-Version anzubieten ist viel zu viel Aufwand und für Unternehmen wie Oracle nicht machbar. Die Verwaltung solcher umfangreicheren Releases (bis zu sieben gleichzeitig zu unterstützende Versionen!) bremst zudem die Entwicklung auf anderen Gebieten.

Angular beispielsweise setzt auf sehr engmaschige Releases. Nahezu jede Woche liefert Google kleinere Patches zu Angular aus, monatlich Minor Releases und alle halbe Jahre eine Major Version, eine LTS-Version gibt es nur einmal im Jahr. In der Angular-Community stößt dieser Releaseplan auf offene Ohren. „Es ist wohl ein Mittelweg, der die Anforderungen aller Parteien (Angular-Team, große Firmen, agile Firmen etc.) gut genug bedient“, erklärt Angular-Experte Manfred Steyer.

Was Javas neues Release-System für Entwickler und Unternehmen bedeutet, diskutieren wir auch auf der JAX 2018:

BoF: Sag mal, wie läuft das mit dem Support nach Java 10?
Dienstag, 24. April, 16:30 – 17:30

Diskutieren Sie mit!

Zur Kasse bitte

Für das Oracle JDK gibt es einen LTS, für das OpenJDK nicht. Wer in Zukunft auf frei verfügbare OpenJDK-Versionen setzt, läuft Gefahr, wichtige Sicherheitspatches nicht oder nur deutlich verzögert in seiner Umgebung nutzen zu können. Stellen wir uns dieses Szenario vor: Wenn wir heute eine Applikation mit JDK 10 in Produktion bringen, und in einem Jahr wird ein dann auftretendes Sicherheitsloch gestopft, haben wir mit OpenJDK das Nachsehen. In einem Jahr werden wir bei Java 12 sein, der Patch läuft allerdings erst in den Entwicklungsbranch des nächsten Major Release und wird dann schließlich erst mit 13 verfügbar sein.

Dazu Sharat Chander: „You’re missing out on all the performance benefits, all the security improvements by staying on an olden version.“

Sehen Sie das Problem? Damit müssen wir dann noch fast ein halbes Jahr warten, bis ein entsprechendes Update kommt. Doch damit genug, wir müssen von 10 auf 13 springen. Die Alternative wäre, den Patch selbst auf die laufende Java-Version rückwärts zu portieren und damit ein selbstkompiliertes JDK einzusetzen (Kasten: „Lieber lassen“).

Zwei Faktoren sind nicht ganz ohne: Der mit einer glühenden Nadel gestrickte Workaround kostet nicht nur Zeit, sondern gleicht einem Tanz auf einem Vulkan. Wer will schon die Verantwortung für ein selbst gepachtes System übernehmen?

Lieber lassen

Nehmen wir beispielsweise an, in Java 12 taucht ein Bug auf. An sich schon suboptimal, doch noch schlimmer wird es, wenn wir versuchen, ihn selbst zu fixen. Wir arbeiten mit Java 10, um einen eigenen Patch zu stricken, brauchen aber gegebenenfalls die Codeschnipsel aus 11 und 12. Alternativ können wir versuchen, den Patch auf den für Java 10 relevanten Teil zu reduzieren.

Richtig, das klingt nach viel Arbeit und ist ziemlich heikel. Dieser Workaround ist brandgefährlich, da wir nicht ausschließen können, dass unsere Flickschusterei ein Loch an anderer Stelle aufreißt.

Da haben wir den Salat

Kein Zweifel, Oracles Entschluss, etwas Schwung in die Entwicklung von Java zu bringen, war nicht nur richtig, sondern auch wichtig. Mitunter Jahre auf ein noch so kleines Feature warten zu müssen, macht einfach keinen Spaß und ist längst nicht mehr zeitgemäß. Zeitbasiert neue Java-Versionen auszuliefern, löst dieses Problem, verstärkt allerdings gleichzeitig auch ein anderes.

Klar, Oracles Support kostet nicht erst seit Java 10 Geld. Wer für Support nicht bezahlen will, muss sich nun allerdings Gedanken machen. Die kürzere Lebensdauer der Releases zwingt OpenJDK-Nutzer jedoch, sich mit dem Thema Rückwärtskompatibilität auseinanderzusetzen. Entwickler stehen zwei Wege offen: Entweder sie wechseln auf Oracles kostenpflichtiges Angebot oder springen von Release zu Release.

AdoptOpenJDK plant einen Backport für LTS-Versionen | Quelle: www.twitter.com

Michael Vitz von Innoq erklärt, was das bedeutet: „Setzt man bereits auf das JDK9, so ist ein Upgrade jedoch Pflicht. Mit dem Erscheinen von JDK9 hat Oracle die Supportzeiträume geändert. JDK9 erhält mit dem Release von JDK10 nämlich keine Securityupdates mehr. Lediglich JDK8 als sogenanntes LTS-(Long-Time-Support-)Release erhält parallel zu JDK10 noch Updates. Ist man also aktuell noch auf JDK8, so kann es sich lohnen, auf JDK11 im September zu warten, da dieses das nächste LTS-Release wird.“

Das Problem löst sich dadurch nicht in Luft auf. Möglicherweise liegt es an der Java-Community, es zu lösen. AdoptOpenJDK beispielsweise stellt Java-Entwicklern vorkonfigurierte OpenJDK-Binärdateien aus einem vollständig offenen Satz von Build-Skripten und Infrastruktur zur Verfügung. Das Projekt plant laut Steve Wallin, IBM Runtime Technologies Program Director, Änderungen an LTS-Versionen zurückzuportieren.

Geschrieben von
Niko Köbler
Niko Köbler
Niko Köbler ist freiberuflicher Software-Architekt, Developer & Trainer für Java & JavaScript-(Enterprise-)Lösungen, Integrationen und Webdevelopment. Er ist Co-Lead der JUG Darmstadt, schreibt Artikel für Fachmagazine und ist regelmäßig als Sprecher auf internationalen Fachkonferenzen anzutreffen. Niko twittert @dasniko.
Carina Schipper
Kommentare

Schreibe einen Kommentar

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