© Gudella, 123RF

Im September soll die neue Java-Version 11 erscheinen. Sie schlägt eine neue Marschrichtung ein, die auch Unternehmen und Entwickler betrifft. Das lang ersehnte Aufräumen der Sprache und ihrer Runtime sowie Änderungen an Oracles Lizenzpolitik machen diese Version faktisch zur wichtigsten seit Java 8.

Auf den Top-10-Listen für Entwickler steht Java seit Jahren unangefochten auf einem der ersten Plätze. Zugleich gilt es inzwischen vielen als “Cobol der Neuzeit”. Grund dafür ist auch die Kombination aus Schnecken-ähnlicher Entwicklung, sturem Festhalten an Rückwärtskompatibilität und monatelangen Verspätungen der Versionen 8 und 9.

Als Gegenmittel verschrieb Javas Chefarchitekt Mark Reinhold vor zwei Jahren eine neue Releasepolitik mit halbjährlichen Releases [1]. Wie die Versionen 10 und 11 zeigen, machte Reinhold keine leeren Versprechen: Oracle und das Open-JDK-Projekt bieten die Neuversion pünktlich zum Download [2] an.

Wohl nur wenige schenkten damals einer weiteren Ankündigung aus dem Blog Aufmerksamkeit. In ihr ging es um Feature-, Update- und Long-Term-Support-Releases (LTS). Passend zum Cobol-Image waren viele Entwickler in den letzten zehn Jahren mit höchstens drei bis vier Java-Versionen unterwegs und stiegen nur zögerlich auf neuere um. Das war auch im Betrieb kein Problem, denn Oracle stellte in der Vergangenheit bis zu sieben Jahre lang kostenlos Bugfixes und Sicherheitsupdates (Java 6) bereit. Dank der zweijährigen Überlappung von Major-Releases kam zudem nie Eile im Releasewechsel auf.

Der aktuelle Richtungswechsel ändert auch die Releasepolitik. Neue Versionen erscheinen nun halbjährlich und ersetzen ihre Vorgänger ohne Überlappung (Abbildung 1). Für die Oracle-JDK-Versionen 9 und 10 gibt es schon nach sechs Monaten keine Updates mehr. Oracles JDK 11 dürfen Entwickler anders als die Vorgänger kostenlos nur zu Test- und Demozwecken einsetzen, kommerzielle Nutzung ist wie der Langzeitsupport nur noch mit einem Supportvertrag (zirka 25 US-Dollar pro Prozessor und Monat) legal.

Abbildung 1: Javas Release-Kalender sieht halbjährliche Neuerscheinungen vor, jedes dritte Mal in Form von LTS-Versionen.

Nun ist Oracle als Java-Anbieter nicht allein. Seit 2006 betreut das Open-JDK-Projekt den Großteil von Oracles Quellen und treibt Javas Entwicklung voran. Dazu kommt die von IBM entwickelte JVM aus dem Eclipse-Projekt. Zu Unrecht gilt aber vielen Nutzern nach wie vor Oracles JDK als das “echte” Java.

Mit dem Ende des kostenlosen Java-8-Supports im März 2019 stehen diese nun vor der Frage, ob sie auf das weiterhin kostenfreie Open JDK umschwenken oder einen Supportvertrag mit Oracle schließen. Wechselwilligen sichert Oracle Kompatibilität zwischen Oracle JDK 11 und Open JDK 11 zu [3]. Wer die freie Wahl haben möchte, ist so faktisch zum Sprung auf Open JDK 11 gezwungen. Das zieht wegen des mit Java 9 eingeführten Modulsystems Jigsaw [4] aber eventuell Codeanpassungen nach sich.

Alte Zöpfe

Eine weitere bemerkenswerte Java-11-Änderung: Die Entwickler haben Sprache und Standardbibliothek reduziert. Beide wuchsen seit Java 1.0 immer weiter, unter ihnen auch vollkommen unbrauchbare Klassen und Methoden. Selbst offensichtliche API-Fehler wie »Thread#stop()« stecken seit über zehn Jahren in der Sprache und verleiten Anfänger zu Fehlern.

Mit Java 11 fallen endlich die Methoden »Thread#destroy()« und »Thread#stop()« weg, wie auch ein paar Methoden aus dem Security-Manager und der Runtime-Klasse. Wer diese bisher in seinem Code oder in einer Bibliothek pflegt, muss nacharbeiten.

Aus der Standardbibliothek entfernen die Java-Entwickler ganze Module, ersetzen sie aber teils durch externe Bibliotheken. Dies betrifft wohl insbesondere Jax (Java XML Binding) und Jax-WS (XML Web Services), aber auch das Activation Framework, den Corba-Stack und das Transaction-API.

Ein spezieller Streichkandidat sind die Desktop-Technologien. Nach dem Applet fällt mit Java 11 auch der Webstart zur Softwareverteilung weg. Der versorgte noch vor ein paar Jahren mehr als 10000 Desktops in Deutschland, nun suchen Entwickler Alternativen.

Auch das erst 2009 vorgestellte Framework für grafische Bedienoberflächen Java FX fliegt aus der Laufzeitbibliothek. Die Firma Gluon [5] pflegt es als eigenständiges Modul außerhalb von Oracle weiter, ihr Hauptgeschäft sind Java-FX-basierte Tools zur plattformübergreifenden App-Entwicklung.

Grund für diese Entscheidung sind wohl eher Sparpläne als technische Überlegungen. Anders als die verbleibenden Klassiker Swing und AWT trennt Java FX klar Business-Logik (Java), Layout (XML) und Styling (CSS). So lassen sich schnell Desktop-Anwendungen bauen.

Teile der Java-FX-Gemeinde begrüßen die Trennung von Oracle dennoch. Ein richtiges Interesse am Desktop war schon lange nicht mehr zu spüren, auch erwies sich die enge Kopplung von Kernsprache und Java FX häufiger als problematisch. Aktuelle Informationen zu Java FX liefert ein Blog von Jonathan Giles [6].

Hege und Pflege

Richtig bahnbrechende Neuerungen fehlen in einer Release mit Langzeitsupport in der Regel, dafür winken kleine und feine Änderungen. In der Laufzeitumgebung geht es vor allem darum, aktuelle Standards zu unterstützen. Dazu gehört Unicode in Version 10 in Strings und Characters. Das bringt rund 16000 neue Buchstaben hinzu, unter anderem Emojis für Saurier, Saunas und Djins sowie das Bitcoin-Zeichen.

Bei dieser Gelegenheit bekommt die »String#trim()«-Methode noch Verstärkung von »String#strip()«. Das ältere Kommando (Zeile 5 aus Listing 1) entfernt nur das Leerzeichen (Unicode »\u0020«), das neuere in den Zeilen 6 bis 8 auch andere Leerzeichen aus dem Unicode-Standard wie im Beispiel den EM Space (»\u2003«).

01 System.out.println( String.format( "Java %s", System.getProperty( "java.version" ) ) );
02
03 // Änderungen an String
04 var t = "\u0020 a\u2003";
05 System.out.println( String.format( "Trim          '%s'", t.trim() ) );
06 System.out.println( String.format( "Strip         '%s'", t.strip() ) );
07 System.out.println( String.format( "StripTrailing '%s'", t.stripTrailing() ) );
08 System.out.println( String.format( "StripLeading  '%s'", t.stripLeading() ) );
09
10 System.out.println( "IsBlank EM space : " + "\u2003".isBlank() + "; A : " + "A".isBlank() );
11
12 System.out.println( String.format( "Repeat '%s'", "A".repeat( 3 ) ));
13
14 "c\nb\na".lines().sorted().forEach( s -> System.out.println( s ) );
15
16 Files.writeString( Path.of( "//tmp/test.txt" ), "mein Text" );
17 var mt = Files.readString( Path.of( "//tmp/test.txt" ) );
18
19 List<PoJo> objekte = pojos();
20 // ganz alt
21 objekte.sort( new Comparator<PoJo>() {
22     @Override
23     public int compare( PoJo o1, PoJo o2 ) {
24         return o2.getAlter() - o1.getAlter();
25     }
26 } );
27 // Seit Java 8
28 objekte.sort( (PoJo o1, PoJo o2) -> o1.getAlter() - o2.getAlter() );
29 objekte.sort( (o1, o2) -> o1.getAlter() - o2.getAlter() );
30
31 // seit Java 10
32 var lds = pojos();
33
34 // seit Java 11
35 objekte.sort( (var o1, var o2) -> o1.getAlter() - o2.getAlter() );

Passend dazu gibt es jetzt die neue »String#isBlank()«-Methode, »String#repeat()« und das handliche »String#lines()« zum Trennen eines Textes in einem Stream an den Zeilenumbrüchen. Die Ergebnisse zeigt Abbildung 2. Auch das Lesen aus und das Schreiben von Texten in eine Datei verwandeln die neuen Methoden »Files#writeString()« und »Files#readString()« nun in Einzeiler.

Abbildung 2: Für Testzwecke lassen sich einfache Quelltexte neuerdings direkt ausführen.

Der mit Java 9 vorläufig eingeführte »HTTPClient« liegt in der finalen Form vor. Sie unterstützt sowohl das alte HTTP-1.1- als auch das neuere HTTP-2-Protokoll. Dies erlaubt unter anderem den Einsatz kleinerer Header, parallele Übertragungen und deren Priorisierung. Zusammen mit dem aktualisierten TLS-Support (HTTPS) für die gerade erschienene Version 1.3 und dem Schlüsselaustausch für elliptische Kurven befindet sich die Implementierung von Webclients auf der Höhe der Zeit.

In den gleichen Zusammenhang gehört die Pflege der Verschlüsselungsalgorithmen. Hier kam ChaCha20 (RFC 7539) als Nachfolger des inzwischen als unsicher geltenden RC4-Algorithmus hinzu.

Drei weitere Änderungen wenden sich an Hardcore-Entwickler, die jeder Millisekunde und jedem Bit auf die Spur kommen wollen oder müssen. Gerade bei Microbenchmarks ist es fatal, wenn der Garbage Collector zuschlägt und die Laufzeiten verfälscht. Der neue Epsilon Garbage Collector tut in der Situation gar nichts und sorgt für konstante Laufzeiten. Ansonsten ist er kaum zu gebrauchen, da ohne Aufräumen natürlich der Speicher vollläuft.

Interessanter ist der nur unter Linux verfügbare experimentelle ZGC Garbage Collector. Er soll langfristig den aktuell genutzten G1 Garbage Collector ersetzen und noch weniger Overhead erzeugen.

Flugschreiber

Alles andere als experimentell ist dagegen der Java Flight Recorder (JFR, [7]). Das Framework zum Sammeln und Speichern von Laufzeit-Informationen blickt auf eine Historie zurück, die sich von J-Rockit über Bea Systems und Sun bis zu Oracle erstreckt. Bisher ließ sich der Flight Recorder legal nur mit einem Supportvertrag verwenden. Jetzt gehört er zu Open JDK und ist Gemeingut.

Im Vergleich mit anderen Techniken kostet das Datensammeln mit dem Flight Recorder etwa 1000- bis 100000-mal weniger Zeit. Nutzer lassen ihn daher in der Produktion zur Überwachung permanent mitlaufen. Der Flight Recorder lässt sich über ein API, Kommandozeilen-Optionen und JMX steuern – lediglich die Auswertung muss der Entwickler zurzeit noch selbst programmieren. Vom zugehörigen Auswertungswerkzeug JMC [8] finden sich schon die Quellen im Open-JDK-Repository, fertig kompiliert gibt es die Software seit Kurzem unter [9].

Auch an der Syntax gibt es kleinere Anpassungen. Die mit Java 8 eingeführten Lambdas ermöglichen es, Schreibweisen wesentlich zu verkürzen (Listing 1, Zeile 28), unter anderem durch das Weglassen der Typangabe (Zeile 29). So etwas klappt auch außerhalb von Lambdas dank der »var«-Deklaration (Zeile 32), die Entwickler eventuell von C# kennen. Damit gibt es in Java zwei verschiedene Schreibweisen, um auf die explizite Variablendeklaration zu verzichten. Der Einheitlichkeit halber lässt sich das »var« überall wie in Zeile 35 einsetzen.

Gerade für das Testen kleinerer Beispiele kommt Java auch mit einem netten Gadget, wie in Abbildung 2 zu sehen. Quelltext startet der Tester ohne voriges Kompilieren auf der Kommandozeile:

java HelloWorld.java

Für größere Programme arbeitet er hingegen wie gewohnt. Intellij und Eclipse können schon mit Java 11 umgehen, Netbeans migriert zurzeit von Oracle zu Apache und hinkt daher etwas hinterher.

Entscheidungsfindung

Seit Version 9 hat die Java-Entwicklung wieder an Fahrt aufgenommen und zwei der wesentlichen Aufgaben angepackt. Die Entwickler haben zum einen die Laufzeitbibliothek aufgeteilt, was den Hauptspeicherbedarf und die Startzeit angenehm reduziert. Zum anderen erfolgte ein schon seit Jahren überfälliges Aufräumen des Java-API. Die dafür herausgepickten Kandidaten empfahlen sich in einer Mischung aus “lange überfällig”, “selten benutzt” und “nicht mehr Teil von Oracles Strategie”.

Da Betroffene die benötigten Module bei Bedarf nachladen können, hält sich der Aufwand auch für sie in Grenzen. Alle anderen dürfen sich über ein Java mit reduziertem API und weniger Platzbedarf auf der Festplatte freuen. Aber damit findet das Aufräumen noch keinen Abschluss. Für Java 12 steht unter anderem der Javascript-Interpreter Nashorn [10] auf der Abschussliste. Ob der Rausschmiss von Java FX als Kollateralschaden beklagenswert ist oder das UI-Framework ohne Oracle besser gedeiht, wird erst die Zukunft zeigen.

Klar scheint allerdings, dass die nächste Zeit viele Java-Nutzer vor die Entscheidung stellt, von wem und in welchem Takt sie künftig ihr JDK und JRE beziehen. Den seit Jahren gewohnten kostenlosen Rundum-Service mit automatischen Updates will Oracle in Zukunft jedenfalls nicht mehr bieten. Wahlmöglichkeiten gibt es zum Glück reichlich. Neben dem Wechsel auf das kostenlose Open JDK bietet sich der kommerziellen Support durch Oracle, Azul [11] oder den Linux-Distributor der Wahl an.

Was die aktuelle Version angeht, bleiben künftig nur zwei sinnvolle Alternativen: Entweder bleibt der Anwender für die nächste Zeit bei Java 8 und bezieht dafür kommerziellen Support. Oder er steigt direkt auf die neue Version 11 um. Dank der oben aufgezählten diversen Änderungen seit Version 8 könnte sich dieser Umstieg durchaus lohnen.