Java 14 - LTS oder stets aktuell?

Java 14 – LTS oder stets aktuell?

Die Entwicklungen an Java 14 sind im vollen Gange. Bis zum Release im März 2020 ist noch etwas Zeit, auch um zu überlegen, ob sich ein Update auf die neue Version wirklich lohnen kann.

Die inzwischen nicht mehr ganz so neue Update-Politik von Java stellt Entwickler und Management jedes halbe Jahr wieder vor die Frage, ob man die Stabilität der LTS-Versionen der jeweiligen aktuellen Version vorzieht. LTS steht hier für Long Term Service, also für die längerfristige Unterstützung und Versorgung mit (Sicherheits-)Updates. Ich möchte in diesem Beitrag die Frage klären, ob es nun mit Java 14 an der Zeit ist, um den sicheren Hafen der lange unterstützten Version 11 zu verlassen.

Die Neuerungen betreffen dabei verschiedene Aspekte der Java-Welt. Änderungen an der Virtual Machine kommen dabei häufig Bestandsanwendungen in Form von Performanceverbesserungen zugute. Erweiterungen an der Sprache erlauben Entwicklern, übersichtlicheren und besser wartbaren Code zu schreiben. Verbesserungen im Bereich der Java Runtime Library bringen neue Funktionen und Vereinfachungen in die Java-Programmierung. Schließlich gibt es noch Änderungen am Tooling, also den Hilfsprogrammen im Umgang mit Java-Code und Anwendungen.

Modifikationen an der Virtual Machine

In die Änderungen an der Virtual Machine – der Ausführungsplattform für kompilierten Java Code – betreffen bis Java 14 vornehmlich die Garbage Collectoren (Java 12: JEP-189, JEP-344, JEP-346; Java 13: JEP-351; Java 14: JEP-345, JEP-363, JEP-364, JEP-365, JEP-366). Hier gibt es nötige Aufräumarbeiten und Performanceverbesserungen. Die Rückgabe von nicht genutztem Speicher an das Betriebssystem dürfte insbesondere für Container-Umgebungen interessant sein.

Die NullPointerException schwebt seit jeher wie ein Damoklesschwert über dem Code eines jeden Java-Entwicklers. Mit Java 14 (JEP-358) wird die NullPointerException zwar nicht Geschichte sein, jedoch sollen zusätzlich zur Zeilenangabe noch weitere hilfreiche Informationen über den Ursprung der NullPointerException geliefert werden.

Eine weitere Neuerung ist das Class-Data-Sharing (Java 12: JEP-341; Java 13: JEP-350), das es erlaubt, Anwendungen dadurch schneller zu starten, dass ein Cache der verwendeten Klassen – beispielsweise beim Durchlauf einer Anwendung – angelegt wird.

Außerdem werden noch die unterstützten Plattformen (Ports) im Bereich der ARM, Solaris und SPARC Prozessoren aufgeräumt (Java 12: JEP-340; Java 14: JEP-362).

Neuerungen in der Sprache

Die neuen Switch Statements (Java 12: JEP-325; Java 13: JEP-354; Java 14: JEP-361) sollen mit Java 14 endgültig Einzug in den Standard halten. An der Syntax ändert sich wenig, so wird aus „case A:“ lediglich „case A ->“. Während die neue Syntax auch dafür sorgt, dass das fehleranfällige Fall-Through-Verhalten abgeschafft wird, bleibt leider das Problem, dass auch die neuen Switch Statements nicht vollständig sein müssen (z.B. kann ein Switch Statement über Wochentage weiterhin den Fall „Donnerstag“ ignorieren). Schade! Im Gegensatz zu den Switch Statements liefern die Switch Expressions auch einen Rückgabewert. Bei den Expressions wird allerdings gefordert, dass alle Fälle vollständig abgedeckt sind.

  int numLetters = switch (day) {
    case MONDAY, FRIDAY, SUNDAY -> 6;
    case TUESDAY                -> 7;
    case THURSDAY, SATURDAY     -> 8;
    case WEDNESDAY              -> 9;
  };

Die Textblöcke (Java 13: JEP-355; Java 14: JEP-368) sollen die Möglichkeit bieten, mehrzeilige Strings in Java definieren zu können, ohne sich übermäßig um ein Escapen der Zeilenumbrüche kümmern zu müssen. Eine schöne Alternative zu den hässlichen zusammengesetzten Konnotationen, die sich derzeit noch in vielen Codebasen finden. Ein Segen, wenn man es mit Schnipseln von HTML, Javascript oder SQL zu tun hat, auch wenn man im Hinterkopf behalten sollte, dass komplexere Ressourcen lieber in eigene Dateien auslagert werden sollten.

  String html = """
                <html>
                  <body>
                    <p>Hello, world</p>
                  </body>
                </html>
                """;

Eine erweiterte Syntax für instanceof (Java 14: JEP-305) erlaubt die direkte Deklaration einer neuen Variable. Das ist eine komfortable Erweiterung, da auf fast jedes instanceof ein Cast auf die entsprechende Klasse folgt.

  if (obj instanceof String) {   
    String s = (String) obj;   
    // use s
  }

Zu guter Letzt sind noch Records (Java 14: JEP-359) im Gespräch. Anstatt eine klassische Klasse – mit all dem (un)nötigen Code – zu definieren, können mit Records kleine Datenklassen in ungeahnter Kürze angelegt werden (zumindest wenn man den typischerweise sehr detaillierten Java-Code gewöhnt ist). Für die Zukunft (jenseits von Java 14) kann man die Records im Hinterkopf behalten.

  record Point(int x, int y) { }

Fortschritte der Java Runtime Library

Eine Überarbeitung der Socket-API (Java 13: JEP-353) könnte zu Kompatibilitätsproblemen führen. In Businessanwendungen sollte jedoch nicht mehr als ein Update von Bibliotheken für ein Update notwendig sein.

Die Neuerungen der APIs für Speicherzugriffe (Java 14: JEP-352, JEP-370) können im entsprechenden Umfeld zu Performancesteigerungen führen, spielen für die Geschäftslogik jedoch keine Rolle. Gleiches gilt für die neue JVM Constants API (Java 12: JEP-334), welche Vereinfachungen im Umgang mit Bytecode mit sich bringt. Im Entwickleralltag dürften sich diese Änderungen jeweils nur durch ein Versionsupdate einer Drittanbieterbibliothek äußern.

Das Java Flight Recorder Event Streaming (Java 14: JEP-349) erlaubt schließlich die Überwachung der Performance innerhalb der Anwendung.

Änderungen beim Tooling

Mit Java 12 werden Microbenchmarks (Java 12: JEP-230) in das Tooling aufgenommen. Microbenchmarks erlauben die Performance eines kleinen Codestückes – ähnlich einem Unit-Test – zu untersuchen. Microbenchmarking in Java ist eine Wissenschaft für sich, und sollte primär von Entwicklern durchgeführt werden, die tief mit der Materie vertraut sind. Solche Entwickler greifen schon seit langem auf JMH zurück, das auch für die Umsetzung dieses JEP verwendet wird.

Das Packaging Tool (Java 14: JEP-343) erlaubt das Zusammenpacken von Anwendung und Java-VM in einen plattform-nativen Installer, so wird es beispielsweise Endnutzern erleichtert Java-Anwendungen zu installieren.

Auch im Bereich des Toolings kommt es zu Aufräumarbeiten. Das eher unbekannte (un)pack200 Tool (Java 14: JEP-367) wird entfernt, da mit Java 9 bereits zeitgemäße Alternativen bereitgestellt wurden.

Und was nun?

Zunächst gibt es überhaupt keinen Grund zu überstürzten Entscheidungen. Sowohl Java 8 als auch Java 11 werden noch bis September 2022 kostenlosen Support erhalten. In der Zeit des Java-Universums wird dies voraussichtlich Java 19 entsprechen. Zwischendurch wird mit Java 17 auch noch eine weitere LTS-Version erwartet.

Im Betrieb kann man die kontinuierlichen Weiterentwicklungen in Sachen Performance und Garbage Collectors nach einem Kompatibilitätstest mitnehmen. Lediglich die neuen NullPointerExceptions dürften sich in den Log-Files positiv bemerkbar machen. Wirklich lohnen würde sich das jedoch – wenn überhaupt – in einer Container-Umgebung. Hier sollte die JVM bereitwilliger wieder ihren Speicher freigeben.

Switch Expressions, Textblöcke, instanceof-Syntax und Record – viele der Änderungen an der Sprache sind zwar willkommene Schritte, aber grundlegende Neuerungen wie Generics und Annotationen in Java 5 oder Streams und Lambdas in Java 8 stellen sie nicht dar. Für den typischen Entwickler sind die Neuerungen kaum relevant. Wer viel mit Switch Cases oder langen Zeichenketten arbeitet, kann langsam über eine (automatisierte) Modernisierung seines Bestandscodes nachdenken.

Bildquelle: Shutterstock

 

Hinterlassen Sie eine Antwort

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.