Suche
Anwendungen kompilieren, paketieren und ausführen

Java 9 Tutorial: Wir bauen einen Paketshop mit Jigsaw

Alexandru Jecan

©Shutterstock / Millena

Nach langer Erwartung wird Java 9 im Sommer 2017 veröffentlicht. Die neuste Version bietet einige Verbesserungen. Insgesamt 89 Java Enhancement Proposals (JEPs) wurden in Java 9 implementiert. In diesem Artikel stelle ich das Modulsystem des Projekts Jigsaw vor.

Die größte Änderung in Java 9 ist das neue Modulsystem Projekt Jigsaw. Mithilfe von Projekt Jigsaw wird die Programmierung auf Basis von Softwaremodulen in Java 9 möglich. Dieser Artikel erläutert Ihnen einen Teil der wichtigsten Grundlagen des Projekts Jigsaw, deren Aufgabe es ist, das Design eines Standardmodulsystems für das JDK 9 und für die Java-Plattform bereitzustellen. Projekt Jigsaw besteht aus insgesamt sechs JEPs und einem JSR:

  • JEP 200: Modulares JDK
  • JEP 201: Modularer Quellcode
  • JEP 220: Modulare Laufzeit-Images
  • JEP 260: Einkapselung von internen APIs
  • JEP 261: Modulares System
  • JEP 282: JLink
  • JSR 376: Java-Platform-Modulsystem

Java 9 Tutorial – die Serie

Die OpenJDK-Webseite stellt die Ziele von Projekt Jigsaw eindeutig und präzise vor. So sollen die Java-SE-Plattform und das JDK skalierbarer für kleine Geräte sein. Außerdem sollen die Sicherheit und Wartbarkeit der Java-SE-Plattform sowie die Leistung von Applikationen verbessert werden. Zudem steht die einfachere Entwicklung und Wartbarkeit von Bibliotheken und großen Anwendungen auf dem Plan, sowohl für die Java-SE- als auch für die Java-EE-Plattform.

Java-9-Anwendungen bestehen aus Modulen. Bei der Kompilierung und Ausführung unterstützt Java 9 die Angabe von Modulen. Der Java-Compiler und der Java Launcher wurden mit neuen Flags bereichert, um die Kompilierung und die Ausführung von Java-9-Modulen zu ermöglichen. Zu den wichtigsten neuen Optionen zählen die folgenden Flags: –module-source-path, die dem Java-Compiler den Suchpfad für Module mitteilt, –module-path, die dem Java Launcher die Stelle der kompilierten Module mitteilt sowie –module, die das Hauptmodul nennt.

Außerdem wird das neue Konzept modularer JAR-Dateien vorgestellt. Nebenbei wird erklärt, wie man eine modulare JAR-Datei aus .class-Dateien erzeugen und wie sie für die Ausführung der Module verwendet werden kann. Die meisten internen JDK-APIs sind in JDK 9 nicht mehr zugänglich. Quellcode, der solche internen JDK-APIs verwendet, kann im JDK 9 nicht mehr kompiliert werden. Um die Kapselung auszuschalten, wurde eine neue Java-Compiler-Option namens –add-exports eingeführt. Mithilfe dieser Option kann man spezifizieren, ob ein internes JDK-Paket für ein bestimmtes Modul zugänglich sein soll. Ein konkretes Beispiel mit Quellcode wollen wir uns in diesem Artikel ansehen.

Das Konzept des Moduls in Java 9

Ein Modul in Jigsaw ist ein Container mit Paketen. Es enthält Ressourcedateien, nativen Quellcode und einen Moduldeskriptor mit dem Namen module-info.java. Die typische Struktur eines Moduls namens com.javamagazin.meinModul sieht folgendermaßen aus:

src/
  com.javamagazin.meinModul/
    module-info.java
      com/javamagazin/meinModul/
        // meine Java-Dateien

Das kann der Moduldeskriptor

Der Moduldeskriptor entspricht der Datei module-info.java. Um ein Modul zu definieren, muss die Datei module-info.java auf oberster Paketebene innerhalb eines Moduls vorhanden sein. Die Datei enthält das Schlagwort module, gefolgt von dem Modulnamen und der Moduldeklaration in geschweiften Klammern. Die Deklaration eines Moduls ist einfach. In unserem Beispiel wird ein Modul namens com.javamagazin.meinModul in der Datei module-info.java deklariert:

module com.javamagazin.meinModul {
}

In diesem Fall hat das Modul com.javamagazin.meinModul keine Anweisungen. Das heißt, andere Module können nicht darauf zugreifen und es kann auch auf andere Module nicht zugreifen. Das Prinzip der starken Abkapselung wird in Java 9 standardmäßig erzielt. In unserem Fall haben wir standardmäßig eine starke Abkapselung auf Basis des Geheimnisprinzips, weil wir keine Anweisungen innerhalb des Moduls definieren.

Die Datei module-info.java kann nur die Moduldefinition enthalten, eine Java-Klasse kann in der Datei nicht platziert werden. Außerdem werden zwei oder mehrere Moduldeklarationen in einer einzigen module-info-Datei zu einem Kompilierungsfehler führen. Der Moduldeskriptor module-info.java wird zusammen mit dem Quellcode kompiliert. Als Ergebnis werden .class-Dateien generiert, einschließlich des Moduldeskriptors module-info. Alle kompilierten Dateien können dann als modulare JAR-Dateien verpackt werden. Es gibt jedoch mindestens zwei Fälle, in denen wir nicht eine module-info.java-Datei selbst schreiben müssen: Zum einen ist das der Fall, wenn wir eine JAR-Datei auf den Modulpfad setzen. Dann wird eine module-info.java-Datei automatisch generiert, weil wir ein automatisches Modul damit erzeugen. Zum anderen, wenn wir eine module-info.java-Datei für eine bestimmte JAR-Datei mithilfe des jdeps-Werkzeugs automatisch generieren.

Fünf Anweisungen im Moduldeskriptor

Innerhalb eines Moduldeskriptors können fünf unterschiedliche Anweisungen definiert werden: requires, exports, provides, uses und opens. Die Anweisungen fasst Tabelle 1 zusammen.

Anweisung Beschreibung
requires <Name des Moduls> Drückt aus, von welchen anderen Modulen das aktuelle Modul abhängt
exports <Name des Pakets>
(to <Name des Moduls>)
Drückt aus, welche Pakete aus dem aktuellen Modul außerhalb des Moduls exportiert werden
uses <Art des Dienstes> Definiert, dass das aktuelle Modul Instanzen von verbraucht
provides <Name des Diensts> with <Name der Implementierung des Diensts> Definiert, dass das aktuelle Modul die Implementierung von mit bietet
opens <Name des Pakets> Stellt das Paket mit dem Namen zur Deep Reflection zur Laufzeit zur Verfügung

Tabelle 1: Anweisungen an den Moduldeskriptor

Abhängigkeiten erfüllen mit der „requires“-Anweisung

Die requires-Anweisung wird innerhalb der Moduldeklaration verwendet, um das Modul zu definieren, das wiederum das aktuelle Modul benötigt, um seine Abhängigkeiten zu erfüllen. Die Syntax ist requires <Name von Modul>;. Für jedes Modul müssen wir eine separate requires-Anweisung definieren. Wir zeigen ein Beispiel, bei dem das Modul com.javamagazin.modul1 eine Abhängigkeit zum Modul com.javamagazin.modul2 sowie dem Modul com.javamagazin.modul3 hat. Das bedeutet, dass das Modul com.javamagazin.modul1 Typen verwendet, die Teile des Moduls com.javamagazin.modul2 oder com.javamagazin.modul3 sind:

// Moduledeskriptor von Modul "com.javamagazin.modul1"
module com.javamagazin.modul1 {
  requires com.javamagazin.modul2;
  requires com.javamagazin.modul3;
}

Auf diese Weise weiß der Java-Compiler zum Zeitpunkt der Kompilierung, welche Abhängigkeiten ein Modul besitzt. Falls eine einzige Abhängigkeit nicht erfüllt ist, wird die Kompilierung fehlschlagen.

Pakete exportieren

Die exports-Anweisung hat die Aufgabe, ein Paket zum Zeitpunkt der Kompilierung sowie zur Laufzeit zu exportieren. Ein Paket, das nicht exportiert wird, steht für keine anderen Module zur Verfügung. Ein Modul exportiert kein Paket standardmäßig. Das beudetet, dass standardmäßig keine Teile dieses Moduls von anderen Modulen erreichbar sind. Die exports-Anweisung wird im Moduldeskriptor mit dem Schlüsselwort exports, gefolgt von dem Paketnamen, definiert: exports <Name des Pakets>;. Im folgenden Beispiel zeigen wir den Moduldeskriptor des Moduls com.javamagazin.modul2:

// Moduledeskriptor des Moduls "com.javamagazin.modul2"
module com.javamagazin.modul2 {
  exports com.javamagazin.modul2.package1;
}

Das Paket com.javamagazin.module2.package1 wird exportiert. Unter der Voraussetzung, dass das Modul com.javamagazin.modul1 das Modul com.javamagazin.modul2 erfordert, wird das Paket com.javamagazin.module2.package1 im Modul com.javamagazin.module1 zugänglich.

Zugänglichkeitsregeln in Java 9

Die Zugänglichkeitsregeln wurden in Java 9 komplett verändert. Vorher war es z. B. möglich, eine Klasse mit der Zugriffskennung public auszustatten, sie von überall zugänglich zu machen. Das ist in Java 9 nicht mehr der Fall: Es müssen gleichzeitig insgesamt drei Bedingungen erfüllt werden, um Zugänglichkeit zu gestatten:

  • Das erste Modul muss das zweite Modul erfordern, mithilfe der requires-Anweisung im Moduldeskriptor
  • Das zweite Modul muss das Paket exportieren, das das erste Modul benötigt
  • Die Typen in dem exportierten Paket müssen als public definiert werden

In Java 9 werden die Zugänglichkeitsregeln sowohl während der Kompilierung als auch während der Laufzeit auferlegt. Ein Fehler vom Typ IllegalAccessError wird zur Laufzeit ausgelöst, falls die Zugänglichkeitsregeln verletzt werden. Die Zugänglichkeitsregeln werden direkt in der Java Virtual Machine erzwungen. Tabelle 2 zeigt die Zugänglichkeitsregeln in Java 9. Wir nehmen an, dass wir einen Typ haben, der mit einem Zugriffsattribut ausgestattet ist (dritte Spalte):

Modul ist gelesen Paket ist exportiert Typ des Zugriffsattributs Zugänglich im anderen Modul
Ja Ja Public Ja
Ja Ja Protected Nein
Ja Ja (Standardmäßig) Nein
Ja Ja Private Nein
Ja Nein Public Nein
Ja Nein Protected Nein
Ja Nein (Standardmäßig) Nein
Ja Nein Private Nein
Nein Ja Public Nein
Nein Ja Protected Nein
Nein Ja (standardmäßig) Nein
Nein Ja Private Nein
Nein Nein Public Nein
Nein Nein Protected Nein
Nein Nein (Standardmäßig) Nein
Nein Nein Private Nein

Tabelle 2: Zugänglichkeitsregeln in Java 9

Der neue Modulpfad

Projekt Jigsaw stellt ein neues Konzept für den Austausch des Klassenpfads vor: den Modulpfad, eine Sammlung von Verzeichnissen, die Module enthält. Im Gegensatz zum Modulpfad ist der Klassenpfad eine Sammlung von JAR-Dateien. Er erlaubt es, Module anstelle von JAR-Bibliotheken anzugeben. Wenn ein Modul an mehreren Orten vorhanden ist, wird das erste Vorkommen beibehalten und die anderen Vorkommen werden nicht mehr berücksichtigt. Der Modulpfad wird vom Compiler verwendet, um Module zu finden und sie zu lösen. Er kann auch mit dem Klassenpfad gemischt werden. Auch wenn der Modulpfad in Java 9 eingeführt wurde, existiert der Klassenpfad noch und kann in Java 9 entweder eigenständig oder in Kombination mit dem Modulpfad verwendet werden. Insgesamt gibt es drei mögliche Modulpfade in Jigsaw: den Kompilationsmodulpfad, den Applikationsmodulpfad und den Upgrademodulpfad.

Der Kompilationsmodulpfad wird vom Java-Compiler verwendet, um den Ort der Module zu definieren. Er ist eigentlich der Modulkorrespondent des –sourcepath. Die Syntax ist: —module-source-path <Liste von Java-Dateien>. Mit der Option —module-source-path erhält man eine Liste von Java-Dateien, die kompiliert werden müssen. In den meisten Situationen wird die Liste der Java-Dateien riesig sein. Linux und Windows mit Cygwin helfen Ihnen in dieser Hinsicht. Sie können folgenden Befehl eingeben, um die vollständige Liste der Verzeichnisse mit der Erweiterung *.java zu erhalten: $(find . –name „*.java“).

Der Java-Compiler und der Java Launcher verwenden den Applikationsmodulpfad. Er enthält eine Liste von Verzeichnissen, die durch einen Doppelpunkt getrennt sind. Eine unbegrenzte Zahl von Verzeichnissen kann eingegeben werden. Die Syntax ist: –module-path <Name von Verzeichnis1>:<Name von Verzeichnis2>:<Name von Verzeichnis3>. Die Module, die in den Verzeichnissen enthalten sind, können entweder als modulare JAR-Dateien paketiert oder einfach als eigenständige Dateien weiterverwendet werden. Der Java Launcher kann genau das Modul aus dem Modulpfad laden, das er benötigt, weil er diese Informationen aufgrund der Konfigurationen kennt, die in der Moduldeklaration definiert sind.

Der Upgrademodulpfad wird spezifiziert, indem man die Java-Compiler-Option –upgrade-module-path verwendet. Im Open JDK heißt es zu seinem Inhalt: „Compiled definitions of modules intended to be used in place of upgradeable modules built-in to the environment.“

Modulare JAR-Dateien

Ein modulares JAR ist eine JAR-Datei, die den Moduldeskriptor module-info.class enthält und eine Gruppe kompilierter Dateien ersetzt. Ein Modul kann in ein modulares JAR verpackt werden. Eine modulare JAR-Datei kann als Modul in Java 9 fungieren oder als reguläre JAR-Datei auf dem Klassenpfad in Java 8 oder früher. Damit wird Rückwärtskompatibilität gewährleistet. Auf dem Klassenpfad wird die Datei module-info.class einfach ignoriert. Ein modulares JAR kann nur ein einziges Modul umfassen. Das JAR-Werkzeug kann verwendet werden, um ein modulares JAR zu bauen. Die Syntax dafür ist: jar –create –file <Name des Verzeichnisses>/<JAR-Datei.jar> –main-class <Name der Klasse> -C <Outputverzeichnis>. Die Bedeutung der verwendeten Optionen ist:

  • <JAR-Datei.jar>: Spezifiziert den Namen der modularen JAR-Datei, die erzeugt wird
  • –main-class <Name der Klasse>: Setzt die Hauptklasse des Moduls
  • -C <Outputverzeichnis>: Gibt an, ob alle kompilierten Dateien aus dem Verzeichnis <Outputverzeichnis> in die JAR-Datei gespeichert werden sollen

Kompilieren in Java 9

Die Kompilierung von Anwendungen in Java 9 unterscheidet sich von der Kompilierung mit bisherigen Java-Versionen nur, wenn wir zusätzlich Module verwenden. Ein Prozess namens Modulauflösung wird während der Kompilierung in Java 9 gestartet. Er berechnet die minimale Zahl an Modulen, die erforderlich sind, um alle Abhängigkeiten innerhalb unserer Applikation zu erfüllen. Die typische Syntax für die Kompilierung mit dem Modulpfad sieht folgendermaßen aus:

javac --module-source-path  --module-path  -d

Die Option -d spezifiziert das Outputverzeichnis, das die kompilierten Dateien enthalten wird. Die Optionen —module-source-path und —module-path wurden schon vorgestellt. Um kurz zu rekapitulieren: Die Option —module-source-path spezifiziert die Definitionen der Module und bezieht sich nur auf Module, die noch nicht kompiliert wurden. Im Gegensatz zur Option —module-path, welche die Verzeichnisse bestimmt, die schon kompilierte Module enthalten.

Ausführen in Java 9

Die Ausführung von Applikationen in Java 9 unterscheidet sich von der Ausführung mit bisherigen Java-Versionen in der Regel nur, wenn der Modulpfad verwendet ist. Beim Laufen wird das Hauptmodul geladen und anschließend werden alle Abhängigkeiten gelöst. Am Ende wird noch die Hauptklasse ausgeführt. Die Syntax sieht folgendermaßen aus:

java --module-path <Liste von Verzeichnissen mit Modulen> --module <Name des Moduls>/<Name der Hauptklasse>
  • Die Option —module-path oder verkürzt –p entspricht dem Modulpfad.
  • Die Option —module oder verkürzt –m erhält als Parameter den Modulnamen zusammen mit dem Namen der Hauptklasse. Er startet den Auflösungsprozess und findet alle Abhängigkeiten.
  • Die Option –Xdiag:resolver sorgt dafür, dass man nähere Informationen über den Auflösungsprozess sehen kann.

Es gibt jedoch verschiedene Variationen bei der Ausführung einer Applikation in Java 9. Man kann auch ein modulares JAR anstelle eines Hauptmoduls eingeben. Ein modulares JAR kann entweder mit dem Klassenpfad oder mit dem Modulpfad ausgeführt werden.

Ein modulares Beispiel

Wir werden ein einfaches Beispiel zeigen, um die vorgestellten Konzepte besser zu verdeutlichen. Nehmen wir an, wir haben zwei Module: das Modul com.javamagazin.modul1 und das Modul com.javamagazin.modul2. Das Modul com.javamagazin.modul1 besteht aus einer Hauptklasse, die Pakete aus dem Modul com.javamgazin.modul2 verwendet:

// Main.java (Modul com.javamagazin.modul1)
package com.javamagazin.modul1;
import com.javamagazin.modul2.*;
public class Main {
  public static void main(String[] args) {
    Buch buch = new Buch("Java 9", "2017");
    System.out.println("Titel des Buchs ist : " + buch.getTitel());
    System.out.println("Das Jahr der Veroeffentlichung ist : " + buch.getVeroeffentlichungsJahr());
  }
}

Der Moduldeskriptor des Moduls com.javamagazin.modul1 erfordert das Modul com.javamgazin.modul2:

// module-info.java (Modul com.javamagazin.modul1)
module com.javamagazin.modul1 {
  requires com.javamagazin.modul2;
}

Das Modul com.javamagazin.modul2 definiert ein einfaches POJO:

// Buch.java
package com.javamagazin.modul2;
public class Buch {
  private String titel;
  private String veroeffentlichungsJahr;
  public Buch() { }
  public Buch(String titel, String veroeffentlichungsJahr) {
    this. titel = titel;
    this. veroffentlichungsJahr = veroeffentlichungsJahr;
  }
  public String getTitel () {
    return titel;
  }
  public String getVeroeffentlichungsJahr () {
    return veroeffentlichungsJahr;
  }
}

Der Moduldeskriptor des Moduls com.javamagazin.modul2 exportiert das Paket com.javamagazin.modul2. Er sieht folgendermaßen aus:

// module-info.java (Modul com.javamagazin.modul2)
module com.javamagazin.modul2 {
  exports com.javamagazin.modul2;
}

Für die Kompilierung beider Module führen wir folgenden Befehl aus: javac -d output –module-source-path src $(find . -name „*.java“). Als Ergebnis werden im Outputverzeichnis .class-Dateien separat für jedes Modul generiert. Um unsere kleine Anwendung auszuführen, geben wir anschließend folgenden Befehl ein: java –module-path output -m com.javamagazin.modul1/com.javamagazin.modul1.Main.

Die –module-path-Option weist auf das Outputverzeichnis hin, in dem die kompilierten Dateien vorhanden sind. Das Ergebnis können wir in der Konsole anschauen:

Java 9
2017

Im letzten Schritt möchten wir modulare JAR-Dateien erzeugen. Wie wir vorher gelernt haben, kann ein modulares JAR aus nur einem einzigen Modul bestehen. Um ein modulares JAR für das Modul com.javamagazin.modul1 zu erzeugen, führen wir folgenden Befehl aus:

jar --create --file modularJar/modul1.jar --main-class com.javamagazin.modul1.Main -C output/com.javamagazin.modul1

Als Ergebnis wird ein modulares JAR namens modul1.jar im Verzeichnis modularJar erzeugt. Wir können den Inhalt des Moduldeskriptors der modularen JAR-Datei zeigen, indem wir folgenden Befehl ausführen:

jar --file modularJar/modul1.jar --print-module-descriptor

Das Ergebnis sieht folgendermaßen aus:

module com.javamagazin.modul1 (module-info.class)
  requires com.javamagazin.modul2
  requires mandated java.base
  contains com.javamagazin.modul1
  main-class com.javamagazin.modul1.Main

Interne JDK-APIs kapseln

Die meisten internen JDK-APIs sind in Java 9 nicht mehr zugänglich. Jeder Versuch, ein internes JDK-API abzurufen, scheitert mit einem Kompilierungsfehler. Die internen APIs befinden sich im sun.*-Paket, aber nicht nur dort. Es gibt jedoch ein paar Klassen, die zu den internen APIs gehören und weiterhin erreichbar sind: sun.misc.Unsafe, sun.misc.Signal, sun.misc.SignalHandler, sun.reflect.Reflection und sun.reflect.ReflectionFactory. Der Grund ist, dass es keine Ersatzklassen für diese Klassen gibt, sie sind Teil des Moduls jdk.unsupported. Um Zugang auf diese Klassen zu bekommen, reicht es, wenn wir das Modul jdk.unsupported anfordern, weil es alle eigenen Pakete exportiert. Aber was machen wir mit den internen JDK-APIs, die in Java 9 gekapselt werden? Wie können wir trotzdem Zugang ermöglichen? Glücklicherweise gibt es eine ziemlich einfache Lösung, wieder Zugriff auf interne JDK-APIs in Java 9 zu erhalten. Dafür wurde der Java-Compiler mit der Option —add-exports bereichert, die während der Kompilierung eingesetzt werden kann, um ein Paket, das aktuell gekapselt ist, wieder zugänglich zu machen. Das folgende Beispiel macht das interne sun.awt-Paket aus dem Modul java.desktop im Modul com.javamagazin.meinModul zugänglich:

--add-exports java.desktop/sun.awt = com.javamagazin.meinModul

Doch was passiert, wenn wir nur mit dem Klassenpfad arbeiten und bisher kein Modul definiert haben? Wie können wir ein Modul spezifizieren, wenn wir noch kein Modul haben? Dafür gibt es die Konstante ALL-UNNAMED, die dem ganzen Quellcode des Klassenpfads entspricht. Das heißt, falls wir im vorigen Beispiel ALL-UNNAMED statt com.javamagazin.meinModul verwendet hätten, würden wir das Paket sun.awt für den ganzen Quellcode des Klassenpfads zugänglich machen.

Noch ein Beispiel zum Schluss

Wir zeigen ein sehr einfaches Beispiel, das ein internes JDK-API verwendet: sun.net.URLCanonicalizer. Dazu definieren wir ein Modul und eine Hauptklasse:

// Main.java
package com.javamagazin.meinModul;
import sun.net.URLCanonicalizer;
public class Main {
  public static void main(String[] args) {
    URLCanonicalizer urlCanonicalizer = new URLCanonicalizer();
    String url =  urlCanonicalizer.canonicalize("www.google.de");
    System.out.println(url);
  }
}

Der Moduldeskriptor des Moduls com.javamagazin.meinModul enthält keine Anweisungen:

// module-info.java
module com.javamagazin.meinModul {
}

Wir kompilieren:

javac -d out --module-source-path src $(find . -name "*.java")

Da das Paket sun.net in Java 9 gekapselt ist, wird folgende Fehlermeldung angezeigt:

.\src\com.javamagazin.meinModul\com\javamagazin\meinModul\Main.java:3:
error: package sun.net is not visible
import sun.net.URLCanonicalizer;

Wir fügen die —add-exports-Option während der Kompilierung hinzu:

javac -d out --add-exports java.base/sun.net=com.javamagazin.meinModul --module-source-path src $(find . -name "*.java")

Obwohl jetzt eine Warnung ausgegeben wird, ist die Kompilierung diesmal erfolgreich:

\src\com.javausergroup.myModule\com\javausergroup\myModule\Main.java:8: warning: URLCanonicalizer is internal proprietary API and may be removed in a future release

Die Warnung informiert uns darüber, dass der URLCanonicalizer in Zukunft vermutlich entfernt wird.

Fazit

Vor Java 9 war es in Java nicht möglich, Module dynamisch zu verwalten. Das hat sich mit Projekt Jigsaw grundlegend geändert. Projekt Jigsaw stellt ein neues modulares System im JDK vor und ermöglicht den Bau von Anwendungen auf Basis einer modularen Architektur. Es bringt Flexibilität, Wartbarkeit, Sicherheit und Skalierbarkeit auf die Java-Plattform und führt lose gekoppelte Module ein, indem es die Abhängigkeiten zwischen den Modulen klar definiert.

Projekt Jigsaw bringt Entwicklern viele Vorteile. Die Probleme, die mit der JAR-Hölle auf dem Klassenpfad zusammenhängen, werden durch den Einsatz des neuen Modulpfads anstelle des Klassenpfads gelöst. Außerdem kann man mithilfe des Werkzeugs jlink JRE Images erstellen, die nur die benötigten Module enthalten, zusammen mit der minimalen Zahl der Abhängigkeiten. Trotzdem können ein paar Hürden bei der Migration von Java-Applikationen auf Java 9 auftreten. Der nächste Artikel dieser Serie wird anhand praxisorientierter Beispiele zeigen, wie man eine Java-Applikation mit einigen Abhängigkeiten Schritt für Schritt auf Java 9 migrieren kann.

Verwandte Themen:

Geschrieben von
Alexandru Jecan
Alexandru Jecan
Alexandru Jecan ist Diplom-Informatiker und hat mehr als sechs Jahre Erfahrung im IT-Bereich mit Fokus auf Architektur, Softwareentwicklung und Qualitätssicherung von Enterprise-, Web-, Client-Server- und Mobile-Anwendungen.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.