Goodbye Java 8, Hello Java 11

25. September 2018

Das Bemerkenswerte an Java 11 ist wohl, dass es sich dabei um die erste Long-Term Version seit Java 8 handelt. In der Zwischenzeit hat sich auch vieles geändert, wobei der größte Sprung wohl mit „Project Jigsaw“ (Java 9) [1] gemacht wurde. Zudem erreichen wir bald den ersten Meilenstein bei der Abschaltung von Java 8: Im Januar 2019 endet der öffentliche Support für kommerzielle Benutzer [2]. Deswegen sollte man nun dringend mit der Migration von Java 8 auf Java 11 beginnen.

Ein spannender Punkt dabei ist die derzeit noch etwas unklare Bedeutung von „Long-Term“ Support. Im Allgemeinen bietet Oracle nur noch kommerziellen Support (Premium, Extended) an [2, 3], und hat den allgemein öffentlichen Update-Support an die OpenJDK-Gemeinschaft abgegeben [4]. In diesem Zusammenhang erschwert wohl der „Community“-Ansatz von OpenJDK die vorausschauende Zeitplanung. Aber auch große Firmen wie Red Hat geben noch keine konkreten Angaben, wie lange sie Java 11 unterstützen werden [5].

Die Umstellung auf Java 11 umfasst die Schritte „Run-Compile-Modularize“ [6]. Zunächst einmal sollte man versuchen, die Anwendung mit einer Java-11 JDK zu starten. Im zweiten Schritt folgt dann das Kompilieren der Anwendung mit der neuen JDK. Im Prinzip können dabei bereits Probleme auftreten, zumal nun einige Module (Java EE und CORBA) entfernt wurden [7]. Gleiches gilt übrigens auch für JavaFX, welches ab Java 11 nicht mehr in der JDK enthalten sein wird und als Open-Source Projekt weiterentwickelt werden soll [8]. Der letzte Schritt „Modularize“ umfasst die Modularisierung der Anwendung, womit z.B. die Wartbarkeit verbessert werden kann [9]. Das ist sicherlich der aufwendigste Teil, der in der Regel eine Code-Überarbeitung (Refactoring) erfordert. Im Prinzip kann man dabei auch zu dem Ergebnis kommen, dass die Modularisierung einer bestehenden Anwendung nicht mit vertretbarem Aufwand möglich ist. Dann sollten aber umgehend die Weichen für die Entwicklung einer modularisierten Neu-Anwendung gestellt werden.

Ablaufdiagramm; Run, Compline, Modularize

Abbildung 1: Schritte zur Java 11-Lauffähigkeit

Damit zu den eigentlichen Neuheiten bei Java 11. Insgesamt gibt es keine größeren Änderungen, was letztlich auch mit dem neuen Konzept eines kürzeren (halbjährliche) Releasezyklus zusammenhängt. Für bestehende Anwendungen ist wohl der Flight Recorder das interessanteste neue Feature [10]. Dabei handelt es sich um ein vormals kommerzielles Werkzeug zum Aufzeichnen und Sammeln von Laufzeitinformationen einer Java-Anwendung [11, 12]. Da es Ressourcen-schonend ist, eignet es sich insbesondere auch für den Einsatz in der Produktion, und kann dort die Analyse von Problemen unterstützen. Zu beachten ist nur, dass man für die Auswertung der aufgezeichneten Daten das Analyse-Tool „Java Mission Control“ benötigt. Dieses ist noch nicht für OpenJDK verfügbar [13] bzw. in der derzeitig stabilen Variante nur für Entwicklungs-Umgebungen uneingeschränkt verwendbar [14].

Eine sprachliche Neuerung ist die Vereinfachung des var-Typ Syntax im Zusammenhang mit Lambda-Ausdrücken [15]. Des Weiteren ist nun das „On-the-fly“ Laden von Source-Code Programmen [16] möglich, sofern diese aus einer Datei bestehen. Im Prinzip kann man damit auch etwas komplexere Programme schreiben [17], aber im Kern ist diese Funktionalität eher als Einstiegshilfe beim Lernen von Java gedacht.

Technisch wurde der HTTP-Client überarbeitet und ist nun nicht-blockierend bzw. unterstützt die java.util.concurrent.Flow API. Die wesentlichsten sicherheitskritischen Änderungen sind: ein neues effizienteres Key-Agreement Schema [19], neue Verschlüsselungsalgorithmen [20] bzw. die Unterstützung von TLS 1.3 [21]. Ebenso kann ab Java 11 Unicode 10 (inkludiert z.B. Unicode Emoji) verwendet werden [22]. Zudem gibt es noch Verbesserungen bei der Heap Allocation [23] sowie zwei neue Garbage-Collectoren [24, 25].

Fazit: Der Umstieg auf Java 11 lohnt sich vor allem deswegen, da es sich um die aktuelle Long-Term Version handelt und es das Modularisierungs-Konzept von Java 9 inkludiert. Für Bestands-Anwendungen ist die Migration zu empfehlen, da hier die Gefahr besteht, dass der Technologie-Sprung zu groß wird. Ebenso wächst das Risiko, dass die Anwendungen mit späteren Java-Versionen nicht mehr läuft bzw. kompiliert werden kann.

Literatur

[1] https://www.avision-it.de/fileadmin/content/Tech_Board/Java9_AvisionGmbH.pdf2018

[2] https://www.oracle.com/technetwork/java/javase/eol-135779.html

[3] https://jaxenter.de/oracle-lts-java-71850

[4] https://en.wikipedia.org/wiki/Java_version_history

[5] https://access.redhat.com/articles/1299013

[6] https://medium.com/criciumadev/its-time-migrating-to-java-11-5eb3868354f9

[7] http://openjdk.java.net/jeps/320

[8] https://wiki.openjdk.java.net/display/OpenJFX/Main

[9] https://www.developer.com/java/other/modularity-in-java-java-9-modularity-versus-prior-versions.html

[10] http://openjdk.java.net/jeps/328

[11] https://jaxenter.de/java-flight-recorder-57537