Der steinige Weg nach Java 11

Der steinige Weg nach Java 11

Ende September erschien mit Java 11 die nächste Long-Term-Support-Version von Java, sie löst das inzwischen vier Jahre alte Java 8 ab. Die wichtigsten Neuerungen auf einen Blick.

Schnellerer Startup, bessere Unterstützung für Container-Technologien wie z.B. Docker, weniger Ressourcenverbrauch – das sind einige der Gründe, um auf die neue Version zu wechseln. Java 11 bringt im Vergleich zu bisherigen Major-Releases aber auch Änderungen mit sich, die aufhorchen lassen:

  • Das Oracle JDK wird kostenpflichtig
  • Wegfall von Java-EE-Modulen
  • Modularisierung des JRE („Projekt Jigsaw”)
  • Neuer halbjährlicher Releasezyklus
  • Neues Classfile-Format (v55)

Bislang war die Migration auf ein neues JDK recht einfach, denn die meisten Anwendungen liefen auch unter der neuen Version wie bisher. Dies scheint mit Java 11 nun schwieriger.

Was sind die Auswirkungen?

Java bleibt kostenlos

Ja, man kann Java auch weiterhin kostenlos nutzen, nur eben nicht das Oracle JDK. Stattdessen muss man auf das OpenJDK wechseln. Dieses wird auch von Oracle bereitgestellt sowie mit Updates versorgt und bildet insbesondere die Basis für das Oracle JDK.

Dadurch entfällt allerdings die Unterstützung für den Desktop und den Browser, sprich Java-Applets und Webstart-Anwendungen laufen nicht mehr. Für Windows gibt es keinen Installer mehr, stattdessen muss man das JDK als ZIP-File herunterladen, entpacken und in den PATH aufnehmen. Ebenso entfällt der automatische Update-Check, d.h., Administratoren und Anwender müssen sich selbst um die Aktualisierung ihrer Java-Installation kümmern.

Wegfall von Java-EE-Modulen

Das neue JRE enthält manche Packages nicht mehr, die insbesondere von Java-EE-Anwendungen genutzt werden. Dies sind JAXB (eine Technologie, um XML auf Java-Objekte abzubilden), JAX-WS (die Bereitstellung von Webservices z.B. als SOAP via HTTP) und Common Annotations (@PostConstruct, @Generated).

Während Anwendungen diese Technologien bislang implizit nutzen konnten, müssen sie nun als zusätzliche Bibliothek in die Anwendung eingebaut werden. Dadurch reduziert sich die Wahrscheinlichkeit, dass Anwendungen ohne Update auf Java 11 lauffähig sind.

Verkürzter Releasezyklus und neues Classfile-Format

Der harmlos scheinende beschleunigte Releasezyklus führt zu einem erhöhten Druck auf Softwareentwickler ihre Anwendungen auf den neuesten Stand zu halten. Denn mit jedem neuen Release wird sich das Format der class-Dateien ändern, und das hat Auswirkungen auf Technologien, die eben jene Classfiles analysieren. Dies ist zum Beispiel notwendig, um Annotationen auszuwerten oder um Framework-Code transparent zu generieren.

Die Analyse von Classfiles geschieht meist über die Bibliotheken ASM, Javassist, jandex oder bytebuddy. Mit dem Erscheinen neuer Java-Versionen müssen diese also gleichzeitig auch aktualisierte Versionen bereitstellen, um die neuen Classfile-Formate zu verstehen. Allerdings sind diese Bibliotheken teilweise direkt in die Technologien eingebaut, anstatt sie als Abhängigkeit zu definieren. Dies betrifft zum Beispiel Jersey, Weld, Deltaspike oder Spring. Projekte, die diese Technologien nutzen, können also erst auf eine Java-Version wechseln, wenn entsprechend kompatible Versionen zur Verfügung stehen. Für Java 11 sind dies:

  • ASM 7.0
  • Jandex 2.0
  • Javassist 3.24
  • Bytebuddy 1.8.2
  • Jersey 2.27
  • Deltaspike 1.9
  • Spring Boot 2.1
  • Spring (core) 5.1

Auch hier gilt wieder: Hersteller von Anwendungen, die diese Technologien nutzen, müssen mit jedem Java-Update auch selbst Updates für ihr Produkt bereitstellen.

Modularisierung des JRE

Anstelle einer einzigen großen Laufzeitbibliothek ist das JRE nun in mehrere kleinere Module aufgeteilt, diese Maßnahme ist unter dem Namen „Projekt Jigsaw“ bekannt. Die Modularisierung kann auch von Anwendungsentwicklern genutzt werden. Ein Vorteil von Modulen ist, dass man den Zugriff auf Klassen zusätzlich zu den Sichtbarkeiten public, protected, package-private und private einschränken kann.

Neben der bereits erwähnten Classfile-Analyse kann man auch über Reflection die Struktur von Java-Klassen analysieren. Konnte man dies bislang uneingeschränkt auf allen Klassen tun, so schränkt Jigsaw den Zugriff auf sogenannte „geöffnete Packages“ ein. Per Reflection kann man künftig nur auf Klassen aus diesen Packages zugreifen, andere Klassen sind nicht erreichbar, selbst wenn sie als public deklariert sind.

Technologien wie CDI (Contexts and Dependency Injection) haben damit ein Problem, denn sie können nun nicht mehr auf diese Klassen zugreifen, denn dazu müssten die Module die entsprechenden Pakete explizit für CDI öffnen. Jedoch kann ein Modul im Vornherein meist gar nicht wissen, dass es über CDI angesprochen wird. Im Java-EE-Umfeld wird daher die Modularisierung über Jigsaw auf absehbare Zeit keine Rolle spielen.

Das Thema Toolunterstützung

  • Maven
    Um Maven mit einem JRE 11 ausführen zu können, braucht man die aktuellsten Versionen der Standard-Plugins. Wer seine POMs gut pflegt, für den sollte das Update leicht zu handhaben sein.
  • Eclipse IDE
    Eclipse hat einen schlechten Start in Java 11. Obwohl der Releasezyklus an den von Java angepasst wurde, hat man es verschlafen, das zurzeit aktuelle Eclipse 2018-09 mit Java-11-Support auszuliefern. Stattdessen muss der Java-11-Support aus dem Eclipse Marketplace nachgezogen werden – und selbst bei einer frischen Installation geht das nicht ohne irritierende Nachfragen. Des Weiteren ist Eclipse vom Wegfall von JAXB betroffen. Einige Plugins haben noch nicht die notwendigen zusätzlichen Abhängigkeiten eingebaut, so dass es zu Fehlermeldungen beim Starten kommt (insbesondere bei standardmäßig aktivierter News-Anzeige).
  • IntelliJ IDEA
    IntelliJ hat bereits seit Version 2018.2 aus Juli volle Unterstützung für Java 11.

Fit für Java 11?

Wer Java auf dem Desktop einsetzt, der wird wahrscheinlich noch eine Weile bei Java 8 als Standard-Installation bleiben. Zwar sind die Tools, die in der Softwareentwicklung eingesetzt werden, bereits fit für Java 11, wer aber im Unternehmen selbstentwickelte Desktopanwendungen einsetzt, muss insbesondere durch den Wegfalls von JavaFX und Java Webstart mit erhöhten Migrationsaufwänden rechnen. Im Einzelfall ist dann abzuwägen, ob sich die Migration lohnt, also, ob man kostenpflichtigen Oracle-Support einkauft oder auf der letzten kostenlosen (aber dadurch ggf. unsicheren) Java-8-Version bleibt.

Für die Entwickler von Webanwendungen sollte der Umstieg recht zügig möglich sein, wenn sie ihre Dependencies aktuell halten.

In meinem Arbeitsalltag als Softwareentwickler habe ich Java 11 als Standardinstallation im PATH, für einige dedizierte Aufgaben wechsle ich kurzfristig auf Java 8. Glücklicherweise passiert dies in letzter Zeit immer seltener.

 

Bildquelle: Shutterstock

Hinterlassen Sie eine Antwort

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