Java 9 bringt das neue Modulsystem Jigsaw

Ein Jigsaw-Modul ist eine Gruppierung von Java-Packages plus Ressourcen. Ein Modul wird kompiliert, als JAR-File paketiert und als "Modular JAR" auf den neuen Module-Path gelegt.

Der Modul-Deskriptor module-info.java definiert den Modulnamen, alle Modul-Abhängigkeiten und legt die Sichtbarkeitsregeln auf die Inhalte des Moduls fest. Abb.1 zeigt dies beispielhaft für zwei Module moda und modb.

Damit moda überhaupt Klassen aus modb benutzen kann, benötigt es eine "Reads"-Abhängigkeit auf modb (blauer Pfeil in der Abbildung). Dies legt Abhängigkeiten zwischen Modulen über deren Namen fest.

modb definiert über seine "Exports" (roter Pfeil), welche seiner Packages für andere Module sichtbar und zugreifbar sind. Die Granularität eines Exports ist dabei immer ein Java-Package. In unserem Beispiel darf moda nur auf das Package pkgb von modb zugreifen, nicht aber auf dessen interne Package pkgbinternal. Per Default sind keine Packages exportiert: Was ein Modul also nicht ausdrücklich mit Exports freigibt, ist für andere Module nicht sichtbar.

Diese neue Exports-Sichtbarkeit spielt mit den altbekannten Sichtbarkeitsmodifiern von Klassen, Attributen, Methoden (also mit public, private, protected, package-sichtbar) wie folgt zusammen: Die Sichtbarkeitsmodifier gelten unverändert innerhalb eines Moduls – über Modulgrenzen hinweg gelten sie auch, greifen jedoch erst, nachdem Reads und Exports erfolgreich überprüft wurden. Will in unserem Beispiel eine Klasse A aus moda auf eine Klasse B in modb zugreifen, so werden sowohl zur Compile- als auch zur Laufzeit diese Zugriffsprüfungen vorgenommen:

• Check der Readability (neu): Existiert eine Reads-Beziehung von moda zu modb?
• Check der Accessibility (neu): Exportiert modb das Package der Klasse B?
• Erst danach werden, wie bisher, die Sichtbarkeitsmodifier public, private, protected, package-sichtbar für B geprüft.
  • Sind Methoden bzw. Attribute von B public, so sind sie innerhalb des Moduls modb von überall zugreifbar. Aus anderen Modulen wie moda sind sie nur zugreifbar, wenn modb das Package der Klasse B exportiert – denn erst damit wird der Typ B überhaupt nach außen sichtbar.
  • Ist das Package von B exportiert, so sind private Methoden bzw. Attribute – wie bisher – aus anderen Modulen trotzdem nicht zugreifbar. Beim Zugriff über Reflection gelten zusätzliche Regeln, die wir unten erläutern.

Java 9 und Jigsaw: Moduldefinition in der module-info.java

Einen Modul-Deskriptor legt man als Java-Datei an. Er muss als module-info.java im Toplevel-Package abgelegt sein. Wir illustrieren das an einem Beispiel mit vier Modulen moda, modb, modc und modmain.

Listing 1: module-info von Modul moda

module moda {
    // Read-Abhaengigkeiten von moda zu modb und modc
    requires modb;
    requires transitive modc;  // transitive Abhaengigkeit

    // Exports von Packages von moda
    exports pkga1;
    exports pkga2 to modmain;  // ... nur an modmain

    opens pkga3;               // ... nur zur Laufzeit
}

Listing 1 zeigt die module-info von moda mit allen wesentlichen Aspekten eines solchen Modul-Deskriptors:

• Modulname "moda". Die Namenskonvention für Module ist ähnlich wie die für Java-Identifier: So sind Punkt und Underscore im Modulnamen erlaubt, Bindestriche nicht.
• Alle Reads-Abhängigkeiten von moda durch Angabe von requires.
• Exports der Packages, die moda nach außen exportiert. Dabei kann jeder Export gezielt auf ein oder mehrere Zielmodule beschränkt werden (im Beispiel wird pkga2 nur an modmain exportiert).

Jedes Reads und jedes Exports muss in der module-info einzeln angegeben werden! Leider gibt es keine Wildcard-Unterstützung für Exports. Packages bilden – wie bisher – keine echte Hierarchie: Ein Exports von x.y exportiert also x.y.impl nicht mit. Wie erwähnt, wird ein Package nicht exportiert, sofern es in der module-info nicht explizit angegeben ist. Alle Typen solcher "Concealed Packages" sind außerhalb ihres Moduls nicht sichtbar und nicht zugreifbar.

Abb.2 zeigt alle Abhängigkeiten unserer vier Beispiel-Module. Die Beispiele unseres Artikels finden sich allesamt auf Github, zusammen mit unserem DepVis-Tool, mit dem auf Basis von GraphViz solche Jigsaw-Modul-Graphen visualisiert werden können [11].

Der Abhängigkeitsgraph zeigt zusätzlich das Plattform-Modul java.base, das Java-Basis-Klassen der Java-Plattform enthält, unter anderem aus java.lang, java.io, java.util, java.net. Da jedes Modul diese Basis-Klassen braucht, erstellt Jigsaw automatisch eine Abhängigkeit zu java.base (als "requires mandated"). Ein Reads zu java.base ist immer implizit vorhanden und muss nicht in der module-info angegeben werden.

Compile und Run

Die Java-Datei module-info.java wird zusammen mit den Sourcen des Moduls kompiliert. Wir kompilieren in das Zielverzeichnis mods und paketieren jedes unserer vier Module in je ein Modular JAR:

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

jar --create --file=mlib/moda.jar    -C mods/moda .
jar --create --file=mlib/modb.jar    -C mods/modb .
jar --create --file=mlib/modc.jar    -C mods/modc .
jar --create --file=mlib/modmain.jar -C mods/modmain .  

Dem Java-Compiler übergeben wir dabei den Module-Path als mlib: Dort werden Module gesucht, zusätzlich zu den Plattform-Modulen wie java.base. Schon der Compiler prüft, ob alle abhängigen Module vorhanden sind. Zur Compile-Zeit sind zyklische Abhängigkeiten zwischen Modulen nicht erlaubt. Die vier Modular JARs liegen nach obigem Compile- und Paketierungsschritt in mlib ab.

Beim Start unserer Anwendung geben wir dem Java-Launcher ebenfalls den Module-Path mit und starten mit –m die Main-Klasse pkgmain.Main aus Modul modmain.

java --module-path mlib -m modmain/pkgmain.Main

Fehlt eine Modulabhängigkeit auf dem Module-Path oder in der Java-Plattform, so startet die JVM nicht.

Transitive Abhängigkeiten

Reads-Abhängigkeiten zwischen Modulen sind nicht transitiv. Im folgenden Beispiel gibt die Methode createC der Klasse A aus moda eine Instanz von Typ C aus modc zurück. Eine Klasse Main von Modul modmain ruft die Methode auf, erhält also eine Instanz eines C als Ergebnis.

Listing 2: modmain/Main nutzt moda/A 

// Klasse aus Modul modapublic class A {
    // gibt Typ aus modc zurueck
 public C createC() {
        return new C();
    }
}

// Klasse aus Modul modmain (mit reads nur auf moda)public class Main {
   public static void main(String[] args) {

        // kompiliert immer, auch wenn Typ C nicht sichtbar ist
        Object myc1 = new A().createC();

        // kompiliert nur, wenn C in Main sichtbar ist
        pkgc.C myc2 = new A().createC();

...

Listing 2 zeigt, dass eine Klasse in modmain den Rückgabetyp C nur verarbeiten kann, wenn dieser für modmain sichtbar ist. Ein Zugriff von modmain auf modc ist eigentlich nur möglich, wenn modmain ein Reads auf modc besitzt. Nun sollen Abhängigkeiten von moda aber auch dort gekapselt sein: Wer moda benutzt, soll nicht zusätzlich alle Abhängigkeiten von moda kennen müssen.

Solche transitiven Abhängigkeiten kann man in einer module-info als requires transitive deklarieren: Der Modul-Deskriptor von moda in Listing 1 gibt jedem abhängigen Modul automatisch eine transitive Reads-Abhängigkeit zu modc (grüner Pfeil in Abb.2). Das funktioniert auch über eine Kette von requires transitive-Abhängigkeiten.

requires transitive ist ein mächtiges Feature. Damit lassen sich Aggregator-Module definieren, die selber keinen eigenen Inhalt besitzen, sondern nur Abhängigkeiten zu anderen Modulen an einer zentralen Stelle unter ihrem Namen bündeln. Die Java-Plattform hat über diesen Mechanismus die Sprachprofile java.compact1,2,3 definiert (die aber im finalen Java 9-Release nicht mehr enthalten sind):

Listing 3: Aggregator-Module

cd $JAVA_HOME/jmods
$JAVA_HOME/bin/jmod describe java.compact*.jmod
java.compact1@9-ea
    requires mandated java.base
    requires transitive java.logging
    requires transitive java.scripting
...
java.compact2@9-ea
    requires mandated java.base
    requires transitive java.compact1
    requires transitive java.rmi
    requires transitive java.sql
    requires transitive java.xml
...
java.compact3@9-ea
    requires mandated java.base
    requires transitive java.compact2
    requires transitive java.compiler
    requires transitive java.instrument
    requires transitive java.management
    requires transitive java.naming
    requires transitive java.prefs
    requires transitive java.security.jgss
    requires transitive java.security.sasl
    requires transitive java.sql.rowset
    requires transitive java.xml.crypto
...

Bei den neuen Exports-Sichtbarkeitsregeln geht es letztlich immer um Typensichtbarkeit, nachstehend gezeigt an "Ableitung", "Interface" und "Exceptions". Zur Laufzeit verlieren Objekte ihren konkreten Typ an der Modulgrenze nicht. Der Typ ist außerhalb seines Moduls jedoch nur sichtbar und nutzbar, wenn sein Package exportiert wurde (s. unsere Github-Beispiele "example_derived_private-package-protected" und "example_exceptions"[11]).

Betrachten wir zunächst folgende Ableitungshierarchie (vgl. auch Abb.3):

• Das exportierte Package pkga enthält die Klasse Data.
• Das nicht exportierte Package pkgainternal enthält die abgeleitete Klasse InternalData.

Eine Factory-Klasse erzeugt Instanzen von Data (s. Listing 4). Sie ist exportiert und kann aus anderen Modulen aufgerufen werden:

Listing 4: Factory zur Erzeugung von Data-Instanzen

package pkga;

import pkgainternal.*;

public class Factory {
    public Data createData() { 
        return new Data(); 
    }

    public Data createInternalData1() {
        return new InternalData(); 
    }

    public InternalData createInternalData2() {
        return new InternalData(); 
    }
}

Ein Aufruf der Methoden createData bzw. createInternalData1 kompiliert, denn ihr Ergebnistyp Data ist ebenfalls exportiert. Dagegen führt ein Aufruf von createInternalData2 zu einem Compile-Fehler, denn InternalData ist nicht exportiert. Ein Aufruf von createInternalData1 liefert eine Instanz von InternalData gekapselt als dessen Oberklasse Data. Das kompiliert, denn nach außen ist der Typ der Oberklasse ja sichtbar. Ein Cast auf die nicht sichtbare Unterklasse InternalData ist dagegen nicht möglich und verhindert einen Aufruf InternalData-spezifischer Methoden.

Analog ist das Verhalten bei Interface und Implementierung: Wäre Data ein Interface, so erhielte eine Klasse in einem anderen Modul eine Implementierungsinstanz, sähe aber nur den Interface-Typ und die dort spezifizierten Methoden. Und genauso verhalten sich auch Ableitungshierarchien von Exceptions: Wird ein eigener Exception-Typ definiert, aber nicht aus seinem Modul exportiert, so ist er in anderen Modulen nicht sichtbar. Solche interne Exceptions können über Modulgrenzen geworfen werden, außerhalb aber nur als Oberklasse wie Exception oder RuntimeException gefangen werden.

Zugriff mit Reflection?

Die beschriebenen Sichtbarkeitsregeln greifen sowohl zur Compile- als auch zur Laufzeit. Auf nicht exportierte Packages kann aus anderen Modulen nicht zugegriffen werden, auch nicht per Reflection. Was bei der Anwendungsentwicklung sinnvoll ist, gilt in dieser Schärfe nicht für technische Frameworks wie Spring (für Dependency-Injection) oder Hibernate (zur Persistierung von Datenklassen).

Der Umgang mit Reflection in Jigsaw hat 2016 einiges Hin und Her erlebt und wurde mit verschiedenen Konzepten umgesetzt. Im September 2016 entschied man sich letztlich, "Strong Encapsulation" umzusetzen. Dabei unterscheidet man "Shallow" und "Deep Reflection":

• Shallow Reflection ist ein Reflection-Zugriff, der "sowieso" möglich wäre, weil ein Typ auch direkt statisch nutzbar ist.
• Deep Reflection bedeutet, dass ein Zugriff per Reflection auf einen Typ durchgeführt wird, der eigentlich nicht zugreifbar ist, zum Beispiel weil er private oder protected ist. Dies war bis Java8 durch setAccessible(true) möglich und ist nun nicht mehr per se erlaubt.

Seit dem Jigsaw-Build 142 gibt es einen neuen Ansatz, der den Export zur Laufzeit für Reflection und die Kapselung vor Deep Reflection vereinigt: opens erlaubt Zugriff nur zur Laufzeit, nicht zur Compile-Zeit und öffnet ein Package für "Deep Reflection" mit setAccessible(true). Ist ein Package eines Moduls also mit opens markiert, so kann eine externe Bibliothek wie zum Beispiel "Spring per Deep Reflection" darauf zugreifen, also auch private Klassen sehen und instanzieren.

Tabelle 1: opens, exports und mögliche Zugriffe zur Compile- und Laufzeit

Als syntaktischen Zucker kann man ein Modul als "Open Module" beschreiben, womit automatisch alle Packages des Modules mit opens geöffnet werden.

Binding von Modulen zur Startzeit mit uses/provides

Mit uses/provides werden Abhängigkeiten nicht statisch zur Compile-Zeit, sondern erst zur Startzeit aufgelöst. Das illustrieren wir am Beispiel eines JDBC-Treibers: Dessen Auswahl wird in Anwendungen i.d.R. erst zur Startzeit festgelegt (unser Github-Beispiel "example_uses-provides" [11]).

Listing 5 zeigt, wie das Java-Modul java.sql (oben) die Schnittstelle java.sql.Driver über uses definiert, die ein Treiber implementieren muss: Das Modul com.mysql.jdbc (unten) bietet mit provides eine solche Implementierung an:

Listing 5: Uses/Provides

module java.sql {
...
   // Definiert Schnittstelle und exportiert sie
   uses java.sql.Driver;
   exports java.sql;
}


module com.mysql.jdbc {
   requires java.sql;
...
   // Implementiert Schnittstelle?
   provides java.sql.Driver with com.mysql.jdbc.Driver;
}

Zur Laufzeit stellt java.util.ServiceLoader Implementierungen einer Schnittstelle zur Verfügung. Er bietet alle beim Start vorhandenen Implementierungen über einen Iterator an, die Auswahl muss die Anwendung selbst vornehmen.

Split Package ist nicht erlaubt

Module müssen disjunkte Packages haben, zwei oder mehr Module dürfen also kein Package gleichen Namens enthalten. Ein solches "Split Package" auf zwei oder mehr Module führt zu Fehlern (s. Github-Beispiel "example_splitpackage" [11]):

• Werden Module mit namensgleichen Packages gemeinsam kompiliert, so führt das zu einem Compile-Fehler.
• Werden solche Module getrennt (erfolgreich) kompiliert, so führt ein gemeinsames Laden zu Laufzeitfehlern beim JVM-Start.

Diese Restriktion gilt selbst für interne "Concealed Packages", also für Packages, die gar nicht exportiert sind. Und sie gilt selbst für Packages, die keine Klassenduplikate in den betroffenen Modulen enthalten!

Erweiterung des statischen Modells

Der Modul-Deskriptor module-info muss zur Compile-Zeit vollständig vorhanden sein. Da module-info zu einer .class-Datei kompiliert wird, kann man diese im JAR nicht einfach ändern. Man kann jedoch per Kommandozeilenoption an Java-Compiler bzw. -Launcher den Module-Deskriptor erweitern. Tabelle 2 zeigt die Möglichkeiten.

Tabelle 2: Kommandozeilenoptionen für javac und java

Module beeinflussen die Organisation von Tests. Wenn wir ein Modul moda mit Blackbox-Tests testen wollen, also Tests gegen die öffentliche Schnittstelle von moda, so können wir unseren Testcode in ein eigenes Test-Modul ablegen. Dieses Test-Modul erhält eine "Reads"-Abhängigkeit auf moda. Die zu testende öffentliche Schnittstelle des Moduls muss exportiert sein und ist somit für die Tests zugreifbar. Abb.4 zeigt das am Beispiel.

Testen mit Whitebox-Tests

Dagegen benötigen Whitebox-Tests, also Tests des Implementierungsgeheimnisses, Zugriff auf nicht-exportierte Klassen von moda. Im Beispiel sollen Klassen aus dem Package pkgainternal getestet werden. Es gibt mehrere Varianten, die Tests zu strukturieren:

• Variante 1a: Wir erstellen, analog zum obigen Vorgehen beim Blackbox-Test, ein separates Modul, modtest.whitebox. Dann müsste moda sein Package pkgainternal exportieren. Diesen Zugriff kann man mit exports to modtest.whitebox einschränken. Damit hat moda aber eine unschöne statische Abhängigkeit zum Testcode!
• Variante 1b: Alternativ kann man den Zugriff zur Compile- und Startzeit gezielt über Kommandozeilenoptionen freischalten:

javac --add-exports modfib/pkgfib.internal=modtest.whitebox
java  --add-exports modfib/pkgfib.internal=modtest.whitebox

Das bedeutet jedoch Aufwand für die Pflege der entsprechenden Skripte.

• Variante 2a: Wir erstellen die Testklassen im zu testenden Modul moda. Dann haben sie Zugriff auf pkgainternal. Wenn die Testklassen aber im Modul moda liegen, werden sie immer mit moda mit-paketiert und mit-deployed.
• Variante 2b: Wir nutzen die Option, ein Modul mit externen Klassen zu patchen (--patch-module). So können wir den Testcode separat verwalten und trotzdem zur Compile- und Laufzeit zu moda dazupatchen, wenn wir Tests ausführen. Der Compile-Aufruf zum Patchen des Moduls lautet:

javac  --patch-module moda=src --add-reads moda=junit -d patches/moda
        ...  src/modtest.whitebox/pkga/WhiteBoxTest.java

Die Option --patch-module moda=src besagt, dass die Testklassen kompiliert werden sollen, als wären sie Teil von moda. Die "Reads"-Abhängigkeit von moda auf junit ist notwendig, da unsere Testklassen eine Reads-Abhängigkeit auf JUnit benötigen.

Starten kann man die Tests mit diesem Aufruf:

java  --patch-module moda=patches/moda --add-reads moda=junit
        ...  -m junit/org.junit.runner.JunitCore pkga.WhiteBoxTest

Wir patchen Testklassen so zur Test-Zeit in das Modul moda.

Der Classpath existiert weiter

In Java 9 wird der Module-Path neu eingeführt, auf dem Module gesucht werden (sozusagen der Ersatz des alten Classpath für Module). Java 9 unterstützt daneben auch weiterhin den altbekannten Classpath. Es ist also weiterhin möglich, "alte" JAR-Dateien bzw. Klassen auf diesem Classpath abzulegen.

In einer reinen Plattform-Migration kann man eine bestehende Java8-Anwendung also zunächst einfach auf dem Classpath belassen und zunächst nur JDK- bzw. JRE-Version nach Java 9 "anheben". Ein solches Vorgehen nutzt keine Module (außer die System-Module der Java-Plattform selbst, z. B. java.base). Vorsicht bei gleichzeitiger Verwendung von Module-Path und Classpath: Eine Klasse wird zuerst auf dem Module-Path gesucht, erst danach im Classpath. Anders als bei Named Modules wird dabei nicht auf Split Package geprüft!

Modulkategorien für die Migration von Java-Anwendungen

Es gibt verschiedene Faktoren, die man bei der Migration einer bestehenden Anwendung nach Jigsaw berücksichtigen muss. Die eigentliche Anwendung muss entsprechend ihrer fachlichen Säulen und technischen Schichten aufgeteilt werden. Bei bestehenden Anwendungen muss man dazu häufig ein gewachsenes Abhängigkeitsgeflecht auflösen. Dies erfordert oft größere Refactorings, zum Beispiel zum Aufbrechen von Zyklen.

Auch das Ökosystem muss eingebunden werden: Manche Third-Party-Bibliotheken stehen vielleicht schon in Modulform (also als Modular JAR) zur Verfügung, andere noch nicht oder eventuell nie (weil sie nicht mehr weiterentwickelt werden). Eine "Big Bang"-Umstellung ist nicht nur riskant, sondern oft unmöglich – eine schrittweise Migration ist wie so oft auch hier der bessere Weg. Jigsaw unterstützt die Migration von Anwendungen durch verschiedene Kategorien von Modulen: Es gibt Explicit Modules, Open Modules (als spezielle Form von Explicit Modules), Automatic Modules und das Unnamed Module.

Tabelle 3: Modulkategorien und ihre Beziehungen