Der Schritt von Java SE 8 hin zu Java SE 9 hat beachtliche dreieinhalb Jahre gedauert. Der Weg war steinig, und das hatte nicht nur mit der eigentlichen Implementierung der Neuerungen zu tun. Bis Java SE 9 im September 2017 endlich ausgeliefert werden konnte, mussten auch viele (firmen-)politische Differenzen ausgeräumt werden.

Nun haben wir also Java 9. Allmählich lernen IDEs wie Eclipse richtig mit den Neuerungen umzugehen, insbesondere also mit dem neuen Modulsystem. Langsam kommt Java 9 auf Rechnern in den Labors von Schulen und Universitäten bzw. in den Entwicklungsabteilungen von Firmen an. Noch langsamer etabliert sich OpenJDK 9 unter Linux. (In Ubuntu 17.10 ist OpenJDK 9 nur in der universe-Paketquelle, in Fedora 27 gilt OpenJDK 9 als Technology Preview. Bei den Enterprise-Distributionen ist ohnedies das Warten auf die nächste Version angesagt, oder natürlich die manuelle Installation abseits der offiziellen Paketquellen.)

Aktualisiert: 4.5.2018

Speed kills

3 1/2 Jahre für eine neue Version ist lang, vermutlich zu lang. Was will man also bei Oracle dagegen tun? Einen schnelleren Versionszyklus etablieren. An sich wäre das ja keine schlechte Idee, aber der aktuelle Plan wirkt vollkommen irrwitzig. In Zukunft soll es halbjährlich eine neue Major-Version geben!

Für Java-Freaks ist das super, die müssen nun nicht mehr jahrelang auf neue Features warten. Was fertig implementiert ist, wird in die jeweils aktuelle Version aufgenommen. Hurra!

Die Frage ist aber, ob bzw. wie das Java-Umfeld mit dieser Geschwindigkeit mithalten kann.

• Werden alle IDEs nun ebenfalls halbjährlich neue Hauptversionen veröffentlichen?

• Wie sollen die neuen Java-Releases so schnell auf alle möglichen Geräte kommen? (Außer Windows und macOS ist ja auch Linux und Android zu berücksichtigen, wo häufig anstelle von Oracle Java die OpenJDK-Version zum Einsatz kommt. In der Regel vergehen einige Monate, bis es hierfür stabile, von den Distributoren offiziell unterstützte Pakete gibt.)

• Wie soll in Java entwickelte Software gewartet werden? Halbjährlich neu kompilieren und ausliefern?

• Welche Java-Version soll im Unterricht verwendet werden?

• Wie sollen gedruckte Dokumentation, Java-Websites, Schulungsunterlagen auf dem aktuellen Stand gehalten werden? (Hier schreibt ein Autor …)

Versionsnummern

Aktuell ist noch nicht einmal klar (siehe diesen heise.de-Artikel), ob die künftigen Java-Versionen nun 10, 11 oder 12 heißen werden, oder ob die von Ubuntu bekannten Nomenklatur übernommen wird, also 18.3, 18.9, 19.3 usw. Update 4.5.2018: beides. Offiziell 10, 11, 12, aber java -version zeigt beide Varianten:

java -version
java version "10" 2018-03-20
Java(TM) SE Runtime Environment 18.3 (build 10+46)
Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10+46, mixed mode)

Angesichts der oben skizzierten Fragen ist das ohnedies nur ein sekundärer Aspekt. Aber die Tatsache, dass noch nicht einmal die Versionsnummer für das in 2 Monaten zu veröffentlichende Java-Release bekannt ist, unterstreicht, wie sehr hier mit der heißen Nadel gestrickt wird.

Wartung und Updates

Aus meiner Sicht die entscheidende Frage ist, in welcher Form Java in Zukunft gewartet wird. Gegenwärtig sieht der Plan anscheinend so aus, dass das jahrelang erwartete Java 9 schon in zwei Monaten obsolet sein wird.

Wer Sicherheits-Updates wünscht, muss dann auf Java 10 umsteigen. (Oder ist es Java 18.3? Na ja, egal.) Und auch wenn Java 10 nur relativ wenig neue Features bieten wird: Kann Oracle wirklich garantieren, dass dieser Versionswechsel ohne Kompatiblitätsprobleme über die Bühne geht?

Java 10 wird aber wohl auch nur ein kurzes Leben haben, es soll im Herbst durch Java 11 (Java 18.9) abgelöst werden. Erst diese Version soll eine LTS-Version sein (Long Time Support), die dann etwas länger gepflegt wird. Wie lange, das weiß man bei Oracle offensichtlich selbst noch nicht (siehe die Oracle Java SE Support Roadmap):

Update 4.5.2018: Java 8 soll bis Januar 2019 offizielle Updates erhalten.

Ubuntu plant offensichtlich, mit Ubuntu 18.04 vorerst OpenJDK 10 auszuliefern, im Herbst ein Update auf OpenJDK 11 mitzumachen und dann dabei zu bleiben. Wie andere Linux-Distributionen vorgehen wollen, ist noch unklar. Aber die Begeisterung darüber, dass Java plötzlich so wie Firefox als heiße Kartoffel zu behandeln ist, wird sich in Grenzen halten.

Vermutlich wäre es am einfachsten, Java-Pakete gleich ganz aus Linux-Distributionen herauszuwerfen und auf Docker oder eine andere Container-Technologie zu setzen. Aber über Nacht sind derartig radikale Änderungen natürlich schwer zu realisieren.

Update 4.5.2018: Ubuntu 18.04 hat Java-10-Pakete, die aber den Namen openjdk-11 tragen. Sie werden im Herbst 2018 auf Java 11 aktualisiert. Fedora 28 enthält ebenfalls Java-10-Pakete. Ob es hier ebenfalls im Herbst ein Update auf Java 11 geben wird, ist mir nicht bekannt.

Fazit

Egal, ob für den produktiven Entwicklungsalltag oder für den Unterricht: Eine Programmiersprache muss eine gewisse Stabilität bieten.

Will man die Sprache gleichzeitig halbjährlich um neue Features erweitern, dann geht aus meiner Sicht kein Weg vorbei, eben zwei Zweige anzubieten: einen stabilen Zweig und einen Entwickler-Zweig. (Das Ubuntu-Modell hat sich diesbezüglich bewährt.)

Prinzipiell scheint sich diese Erkenntnis auch bei Oracle durchzusetzen. Aber da hätte man eigentlich erwarten können, dass Java 9 eine stabile Version ist bzw. wird, und dass man das neue Entwicklungsmodell zuerst ein wenig testet, sich in Ruhe die Wartungsmodalitäten für beide Zweige überlegt und diese öffentlich dokumentiert.

Gegenwärtig sieht es aber so aus, als wolle man Java SE mit maximaler Geschwindigkeit gegen die Wand fahren. Wer nach langem Warten im Herbst 2017 auf Java 9 umgestellt hat, kann sich jetzt eigentlich nur veräppelt vorkommen.

Schöne neue Java-Welt …

Quellen

• http://www.oracle.com/technetwork/java/eol-135779.html
• https://heise.de/-3958492
• https://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-18.04-LTS-OpenJDK-Plans
• https://lists.ubuntu.com/archives/ubuntu-release/2018-February/004275.html
• http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000175.html
• https://blogs.oracle.com/java-platform-group/update-and-faq-on-the-java-se-release-cadence