© DrHitch/Shutterstock.com
Java 9

3 Top-down- und Bottom-up-Migration


In diesem Kapitel beschreibe ich, wie man vorhandene Java-Applikationen auf Java 9 migrieren kann und welche Schwierigkeiten und Probleme damit auftreten können. Man bedenke: Wenn man über Migration redet, muss man klar zwischen der Migration von Applikationen und der Migration von Bibliotheken unterscheiden.

Die Migration von Applikationen bezieht sich auf die Migration unseres Quellcodes. Die Migration von Bibliotheken bezieht sich auf die externen Bibliotheken, die unsere Applikation verwendet. Darüber hinaus gibt es zwei unterschiedliche Arten von Migration: Top-down- und Bottom-up-Migration. Bei der Top-down-Migration werden die JAR-Dateien direkt auf dem Modulpfad platziert. Damit werden aus den JAR-Dateien automatische Module erzeugt. Anschließend muss man für jedes automatische Modul den Moduldeskriptor module-info.java anpassen und gegebenenfalls eine requires-Direktive einfügen. Schließlich lässt sich die ganze Applikation kompilieren und ausführen. Bottom-up-Migration funktioniert anders. Mit jdeps kann man herausfinden, welche Abhängigkeiten eine JAR-Datei des Klassenpfads hat. Nachher wird die Option --generate-module-info von jdeps verwendet, um für jede einzelne JAR-Datei einen Moduldeskriptor module-info.java automatisch zu generieren. Anschließend werden die Moduldeskriptoren überprüft. Falls nötig, werden exports-Direktiven manuell entfernt, um die interne Implementierung zu verbergen. Am Schluss wird die ganze Anwendung kompiliert und ausgeführt. Bei der Ausführung muss man trotzdem beachten, dass die neue Option --add-modules eingesetzt wird, um das Root-Modul zu nennen, damit der Auflösungsprozess gestartet wird. Der Zweck des Auflösungsprozesses besteht darin, alle rekursiven Abhängigkeiten zwischen Modulen zu finden.

Jede neue Java-SE-Version führt einige Inkompatibilitäten mit früheren Releases ein. Die Modularisierung der Java-SE-Plattform bringt viele Vorteile, aber auch viele Änderungen. Laut Oracle sollte Code, der nur APIs der offiziellen Java-SE-Plattform und unterstützte JDK-spezifische APIs verwendet, weiterhin ohne Änderungen funktionieren. Code, der bestimmte Funktionen oder JDK-interne APIs verwendet, kann nicht ausgeführt werden oder unterschiedliche Ergebnisse liefern.

Automatische Module sind der Schlüssel

Die automatischen Module werden für die Migration bestehender Anwendungen auf Java 9 verwendet. Ein automatisches Modul ist ein echtes Modul, das erstellt wird, indem man eine JAR-Datei auf den Modulpfad legt. Das geschieht mit der Option --module-path. Das automatische Modul erfordert (requires) alle vorhandenen Module aus dem System. Das sind alle eigenen Module, alle Module aus dem JDK sowie alle anderen automatischen Module. Das heißt, ein automatisches Modul liest alle diese Module. Außerdem exportiert ein automatisches Modul alle Packages. Ein automatisches Modul kann zudem auf Typen des Klassenpfads zugreifen und eignet sich besonders für Drittanbietercode. Es wird nicht explizit deklariert. Stattdessen wird es automatisch beim Legen einer JAR-Datei auf den Modulpfad erstellt. Wir müssen keine Änderungen an der JAR-Datei vornehmen. Der Name des automatischen Moduls wird aus dem Namen der JAR-Datei abgeleitet. Die Entwickler sind damit nicht gezwungen abzuwarten, bis alle Drittanbieter ihre Bibliotheken modularisieren. Mithilfe des neuen Konzepts ist es möglich, JAR-Dateien schnell zu modularisieren und als Module auf dem Modulpfad statt als JAR-Dateien auf dem Klassenpfad zu verwenden. Natürlich es ist möglich, diese JAR-Dateien weiter auf dem Klassenpfad zu nutzen. In diesem Fall werden sie nicht modularisiert.

Mit jdeps interne JDK-APIs aufspüren

Das Tool Java Dependency Analysis (jdeps) ist ein Werkzeug, das alle statischen Abhängigkeiten einer Bibliothek entdeckt. Es wurde in Java 8 eingeführt, aber in Java 9 mit einigen nützlichen neuen Optionen und Features erweitert. jdeps führt eine statische Analyse der JAR-Dateien durch. Es verfügt über die Option -jdkinternals, um Abhängigkeiten zu allen nicht unterstützten JDK-internen APIs zu finden. Das Tool ist im Allgemeinen sehr nützlich, wenn man sich für die Umstellung auf Java 9 vorbereitet. Wir können überprüfen, ob unsere vorhandenen JAR-Dateien aus dem Klassenpfad JDK-interne APIs enthalten. Indem wir Ersatz für die internen JDK-APIs einplanen, wird der Übergang zu Java 9 einfacher. Wir zeigen ein Beispiel für die Verwendung von jdeps mit der Option –jdkinternals mit der Spark-Bibliothek 2.10. In Listing 3.1 wird geprüft, welche JDK-internen APIs sie enthält.

$ jdeps -jdkinternals spark-core_2.10-2.1.0.jar

spark-core_2.10-2.1.0.jar -> JDK removed internal API

spark-core_2.10-2.1.0.jar -> java.base

spark-core_2.10-2.1.0.jar -> jdk.unsupported
org.apache.spark.serializer.SerializationDebugger$
-> sun.security.action.GetBooleanAction
JDK internal API (java.base)

org.apache.spark.storage.StorageUtils$
-> sun.misc.Cleaner
JDK internal API (JDK removed internal API)

org.apache.spark.storage.StorageUtils$
-> sun.nio.ch.DirectBuffer
JDK internal API (java.base)

org.apache.spark.util.ClosureCleaner$
-> sun.reflect.ReflectionFactory
JDK internal API (jdk.unsupported)

org.apache.spark.util.SignalUtils$$anonfun$1
-> sun.misc.Signal
JDK internal API (jdk.unsupported)

org.apache.spark.util.SignalUtils$ActionHandler
-> sun.misc.Signal
JDK internal API (jdk.unsupported)

org.apache.spark.util.SignalUtils$ActionHandler
-> sun.misc.SignalHandler
JDK internal API (jdk.unsupported)

org.apache.spark.util.SignalUtils$ActionHandler$$anonfun$2
-> sun.misc.Signal
JDK internal API (jdk.unsupported)

org.apache.spark.util.SignalUtils$ActionHandler$$anonfun$3
-> sun.misc.Signal
JDK internal API (jdk.unsupported)

Warning: JDK internal APIs are unsupported and private to JDK implementation that are subject to be removed or changed incompatibly and could break your application.
Please modify your code to eliminate dependence on any JDK internal APIs.

For the most recent update on JDK internal API replacem...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang