Das JPMS (Java Platform Module System), auch unter dem Projektnamen Jigsaw bekannt, ist eine der gr\u00f6\u00dften Neuerungen in Java 9. Im Mittelpunkt steht die starke Kapselung: Implementierungsdetails kann ein Modul geheim gehalten. Selbst Hilfscode innerhalb des Moduls, auch wenn er \u00f6ffentlich ist, darf nicht nach au\u00dfen dringen. Zweitens kommt eine Abstraktion von Verhalten \u00fcber Schnittstellen hinzu, die interne Klassen aus dem Modul implementieren k\u00f6nnen, wobei dem Nutzer die konkreten Klassen nicht bekannt sind. Als dritten Punkt machen explizite Abh\u00e4ngigkeiten die Interaktion mit anderen Modulen klar. Eine grafische Darstellung hilft auch bei gro\u00dfen Architekturen, die \u00dcbersicht \u00fcber Nutzungsbeziehungen zu behalten.<\/p>\n
Klassen, Pakete und Module lassen sich als Container mit unterschiedlichen Sichtbarkeiten sehen:<\/p>\n
\u00b7 Ein Typ, sei es Klasse oder Schnittstelle, enth\u00e4lt Attribute und Methoden<\/p>\n
\u00b7 Ein Paket enth\u00e4lt Typen.<\/p>\n
\u00b7 Ein Modul enth\u00e4lt Pakete.<\/p>\n
\u00b7 Private Eigenschaften in einem Typ sind nicht in anderen Typen sichtbar.<\/p>\n
\u00b7 Nicht \u00f6ffentliche Typen sind in anderen Paketen nicht sichtbar.<\/p>\n
\u00b7 Nicht exportierte Pakete sind au\u00dferhalb eines Moduls nicht sichtbar.<\/p>\n
Ein Modul ist definiert<\/p>\n
1. durch einem Namen,<\/p>\n
2. durch die Angabe, was es exportiert m\u00f6chte und<\/p>\n
3. welches Modul es zur Arbeit selbst ben\u00f6tigt.<\/p>\n
Interessant ist der zweite Aspekt, also dass ein Modul etwas exportiert. Wenn nichts exportiert wird, ist auch nichts sichtbar nach au\u00dfen. Alles, was Au\u00dfenstehende sehen sollen, muss in der Modulbeschreibung aufgef\u00fchrt sein \u2013 nicht alle \u00f6ffentlichen Typen des Moduls sind standardm\u00e4\u00dfig \u00f6ffentlich, dann w\u00e4re das kein Fortschritt zu JAR-Dateien. Mit dem neuen Modulsystem haben wir also eine ganz andere Sichtbarkeit. Aus der Viererbande public, private, paketsichtbar, protected bekommt public eine viel feinere Abstufung. Denn was public ist bestimmt das Modul, und das sind<\/p>\n
– Typen, die das Modul f\u00fcr alle exportiert,<\/p>\n
– Typen f\u00fcr explizit aufgez\u00e4hlte Module,<\/p>\n
– alle Typen im gleichen Modul.<\/p>\n
Der Compiler und die JVM achten auf die Einhaltung der Sichtbarkeit, und auch Tricks mit Reflection sind nicht mehr m\u00f6glich, wenn ein Modul keine Freigabe erteilt hat.<\/p>\n
Wir wollen uns in dem Abschnitt intensiver mit drei Modultypen besch\u00e4ftigen. Wenn wir neue Module schreiben, dann sind das benannte Module. Daneben gibt es aus Kompatibilit\u00e4tsgr\u00fcnden automatische Module und unbenannte Module, mit denen wir vorhandene JAR-Dateien einbringen k\u00f6nnen. Die Bibliothek der Java SE ist selbst in Module unterteilt, wir nennen sie Plattform-Module.<\/p>\n
Die Laufzeitumgebung zeigt mit einem Schalter –list-modules alle Plattform-Module an.<\/p>\n
Beispiel: Liste die ca. 70 Module auf:<\/p>\n
$ java –list-modules<\/b><\/p>\n
java.activation@9<\/p>\n
java.base@9<\/p>\n
java.compiler@9<\/p>\n
\u2026<\/p>\n
oracle.desktop@9<\/p>\n
oracle.net@9<\/p>\n
Im Ordner C:\\Program Files\\Java\\jdk-9\\jmods liegen JMOD-Dateien.<\/p>\n
Das Kommandozeilenwerkzeug jmod zeigt an, was ein Modul exportiert und ben\u00f6tigt. Nehmen wir die JDBC-API f\u00fcr Datenbankverbindungen als Beispiel; die Typen sind in einem eigenen Modul mit den Namen java.sql.<\/p>\n
C:\\Program Files\\Java\\jdk-9\\bin>jmod describe ..\\jmods\\java.sql.jmod<\/b><\/p>\n
java.sql@9<\/p>\n
exports java.sql<\/p>\n
exports javax.sql<\/p>\n
exports javax.transaction.xa<\/p>\n
requires java.base mandated<\/p>\n
requires java.logging transitive<\/p>\n
requires java.xml transitive<\/p>\n
uses java.sql.Driver<\/p>\n
platform windows-amd64<\/p>\n
Wir k\u00f6nnen ablesen:<\/p>\n
\u00b7 den Namen<\/p>\n
\u00b7 die Pakete, die das Modul exportiert: java.sql, javax.sql und javax.transation.xa<\/p>\n
\u00b7 die Module, die java.sql ben\u00f6tigt: java.base ist hier immer drin, dazu kommen java.logging und java.xml<\/p>\n
Die Meldung mit \u201euses\u201c steht im Zusammenhang mit dem Service-Locator \u2013 wir k\u00f6nnen das vorerst ignorieren. Die Kennung \u00fcber die Plattform (windows-amd64) schreibt jmod mit hinein, es ist die Belegung der System-Property os.arch auf dem Build-Server.<\/p>\n
Als Sun von vielen Jahren mit der Entwicklung der Java-Bibliotheken begann, kamen viele interne Hilfsklassen mit in die Bibliothek. Viele beginnen mit den Paketpr\u00e4fixen com.sun und sun. Die Typen wurden immer als interne Typen kommuniziert, doch bei einigen Entwicklern war die Neugierde und das Interesse so gro\u00df, dass die Warnungen von Sun\/Oracle ignoriert wurden. In Java 9 kommt der gro\u00dfe Knall, da public nicht mehr automatisch public f\u00fcr alle Klassen au\u00dferhalb des Moduls ist; die internen Klassen werden nicht mehr exportiert, sind also nicht mehr benutzbar. Es kommt zu einem Compilerfehler, wie in folgendem Beispiel:<\/p>\n
public class ShowRuntimeArguments {<\/p>\n
public static void main( String[] args ) throws Exception {<\/p>\n
System.out.println( java.util.Arrays.toString( jdk.internal.misc.VM.getRuntimeArguments() ) );<\/p>\n
}<\/p>\n
}<\/p>\n
Unser Programm greift auf die VM-Klasse zur\u00fcck, um die eigentliche Belegung der Kommandozeile zu erfragen. In der main(String[] args)-Methode sind in args keine VM-Argumente enthalten.<\/p>\n
\u00dcbersetzen wir das Programm, gibt es einen Compilerfehler (nicht bei einem Java 8-Compiler):<\/p>\n
$ javac ShowRuntimeArguments.java<\/b><\/p>\n
ShowRuntimeArguments.java:3: error: package jdk.internal.misc is not visible<\/p>\n
System.out.println( java.util.Arrays.toString( jdk.internal.misc.VM.getRuntimeArguments() ) );<\/p>\n
^<\/p>\n
(package jdk.internal.misc is declared in module java.base, which does not export it to the unnamed module)<\/p>\n
1 error<\/p>\n
The module java.base does not export the package jdk.internal.misc., so the type jdk.internal.misc.Unsafe is not accessible – as a consequence compilation fails.<\/p>\n
Das Problem dokumentiert der Compiler. Es ist dadurch zu l\u00f6sen, indem mit dem Schalter –add-exports aus dem Modul java.base das Paket jdk.internal.misc unserer Klasse bereitgestellt wird. Die Angabe ist f\u00fcr den Compiler und f\u00fcr die Laufzeitumgebung zu setzen:<\/p>\n
$ javac –add-exports java.base\/jdk.internal.misc=ALL-UNNAMED<\/u> ShowRuntimeArguments.java<\/b><\/p>\n
$ java ShowRuntimeArguments<\/b><\/p>\n
Exception in thread "main" java.lang.IllegalAccessError: class ShowRuntimeArguments (in unnamed module @0x77afea7d) cannot access class jdk.internal.misc.VM (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x77afea7d<\/p>\n
at ShowRuntimeArguments.main(ShowRuntimeArguments.java:3) <\/p>\n
$ java –add-exports java.base\/jdk.internal.misc=ALL-UNNAMED<\/u> ShowRuntimeArguments<\/b><\/p>\n
[–add-exports=java.base\/jdk.internal.misc=ALL-UNNAMED]<\/p>\n
Wir sehen die Ausgabe, das Programm funktioniert.<\/p>\n
Eine Angabe wie java.base\/jdk.internal.misc, bei der vorne das Modul steht und hinter dem \/ der Paketname, ist oft ab Java 9 anzutreffen. Hinter dem Gleichheitszeichen steht entweder unser Paket, welches die Typen in jdk.internal.misc sehen kann, oder \u2013 wie in unserem Fall \u2013 ALL-UNNAMED.<\/p>\n
H\u00e4tten wir das Programm schon erfolgreich unter Java 8 \u00fcbersetzt, w\u00fcrde es zur Laufzeit ebenfalls knallen. Da es nun sehr viel Programmcode gibt, haben die Java-Entwickler bei Oracle das Kommandozeilenprogramm jdeps entwickelt. Es meldet, wenn interne Typen im Programm vorkommen:<\/p>\n
$ jdeps ShowRuntimeArguments.class<\/p>\n
ShowRuntimeArguments.class -> java.base<\/p>\n
<unnamed> -> java.io java.base<\/p>\n
<unnamed> -> java.lang java.base<\/p>\n
<unnamed> -> java.util java.base<\/p>\n
<unnamed> -> jdk.internal.misc JDK internal API (java.base)<\/p>\n
Die Meldung \u201eJDK internal API\u201c bereitet uns darauf vor, dass es gleich \u00c4rger geben wird. <\/p>\n
So kann relativ leicht eine gro\u00dfe Codebasis untersucht werden und Entwicker k\u00f6nnen proaktiv den Stellen auf den Grund gehen, die problematische Abh\u00e4ngigkeiten haben.<\/p>\n
Jedes Java SE-Projekt basiert auf dem Modul java.se, was diverse Modulabh\u00e4ngigkeiten nach sich zieht. <\/p>\n
<pic: java.se-graph.png, \u201eModulabh\u00e4ngigkeiten von java.se\u201c><\/p>\n
Diverse Module sind nicht Teil vom Modul Java SE, unter anderem sind das das Java Activation Framework, CORBA, Transaction-API, JAXB, Web-Services und interne Module, die mit jdk beginnen.<\/p>\n
Starten wir ein Programm mit Bezug zu einem dieser Bibliotheken gibt es einen Fehler. Zun\u00e4chst zum Programm, das ein Objekt automatisch in XML konvertieren soll:<\/p>\n
public class Person {<\/p>\n
public String name = "Chris";<\/p>\n
public static void main( String[] args ) {<\/p>\n
javax.xml.bind.JAXB.marshal( new Person(), System.out );<\/p>\n
}<\/p>\n
}<\/p>\n
Ausgef\u00fchrt auf der Kommandozeile folgt ein Fehler:<\/p>\n
$ java Person<\/b><\/p>\n
Exception in thread "main" java.lang.NoClassDefFoundError: javax\/xml\/bind\/JAXB<\/p>\n
at Person.main(Person.java:6)<\/p>\n
Caused by: java.lang.ClassNotFoundException: javax.xml.bind.JAXB<\/p>\n
at java.base\/jdk.internal.loader.BuiltinClassLoader.loadClass(Unknown Source)<\/p>\n
at java.base\/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(Unknown Source)<\/p>\n
at java.base\/java.lang.ClassLoader.loadClass(Unknown Source)<\/p>\n
… 1 more<\/p>\n
Wir m\u00fcssen das Modul java.xml.bind (oder auch das \u201e\u00dcber\u201c-Modul java.se.ee) mit angeben; daf\u00fcr dient der Schalter –add-modules.<\/p>\n
$ java –add-modules java.xml.bind<\/u> Person<\/b><\/p>\n
<?xml version="1.0" encoding="UTF-8" standalone="yes"?><\/p>\n
<person><\/p>\n
<name>Chris<\/name><\/p>\n
<\/person><\/p>\n
Jetzt gibt es allerdings ein anderes Problem, was auff\u00e4llt, wenn wir einen anderen Typ in XML umwandeln wollen:<\/p>\n
public class Today {<\/p>\n
public static void main( String[] args ) {<\/p>\n
javax.xml.bind.JAXB.marshal( new java.util.Date(), System.out );<\/p>\n
}<\/p>\n
}<\/p>\n
Auf der Kommandozeile zeigt sich:<\/p>\n
$ java –add-modules java.xml.bind Today<\/b><\/p>\n
Exception in thread "main" javax.xml.bind.DataBindingException: javax.xml.bind.JAXBException: Package java.util with JAXB class java.util.Date defined in a module java.base must be open to at least java.xml.bind module.<\/p>\n
at java.xml.bind@9\/javax.xml.bind.JAXB._marshal(Unknown Source)<\/p>\n
at java.xml.bind@9\/javax.xml.bind.JAXB.marshal(Unknown Source)<\/p>\n
at Today.main(Today.java:4)<\/p>\n
Caused by: javax.xml.bind.JAXBException: Package java.util with JAXB class java.util.Date defined in a module java.base must be open to at least java.xml.bind module.<\/p>\n
at java.xml.bind@9\/javax.xml.bind.ModuleUtil.delegateAddOpensToImplModule(Unknown Source)<\/p>\n
at java.xml.bind@9\/javax.xml.bind.ContextFinder.newInstance(Unknown Source)<\/p>\n
at java.xml.bind@9\/javax.xml.bind.ContextFinder.newInstance(Unknown Source)<\/p>\n
\u2026<\/p>\n
Die zentrale Information ist \u201ePackage java.util with JAXB class java.util.Date defined in a module java.base must be open to at least java.xml.bind module\u201c. Wir m\u00fcssen etwas \u00f6ffnen; dazu verwenden wir den Schalter –add-opens:<\/p>\n
$ java –add-modules java.xml.bind –add-opens java.base\/java.util=java.xml.bind<\/u> Box<\/b><\/p>\n
<?xml version="1.0" encoding="UTF-8" standalone="yes"?><\/p>\n
<date>2017-09-02T23:20:52.170+02:00<\/date><\/p>\n
Die Option \u00f6ffnet f\u00fcr Reflection das Paket java.util aus dem Modul java.base f\u00fcr java.xml.bind. Neben –add-opens gibt es das \u00e4hnliche –add-exports, was alle \u00f6ffentlichen Typen und Eigenschaften zur \u00dcbersetzungs-\/Laufzeit \u00f6ffnet; –add-opens geht f\u00fcr Reflection einen Schritt weiter.<\/p>\n
Um Module praktisch umzusetzen wollen wir in Eclipse zwei neue Java-Projekte aufbauen: \u201ecom.tutego.greeter\u201c und \u201ecom.tutego.main\u201c. Wir legen in das Projekt \u201ecom.tutego.greeter\u201c eine Klasse com.tutego.insel.greeter.Greeter an und in \u201ecom.tutego.main\u201c die Klasse com.tutego.insel.main.Main.<\/p>\n
Jetzt ist eine wichtige Vorbereitung in Eclipse n\u00f6tig: Wir m\u00fcssen einstellen, dass \u201ecom.tutego.main\u201c das Java-Projekt \u201ecom.tutego.greeter\u201c ben\u00f6tigt. Dazu gehen wir auf das Projekt \u201ecom.tutego.main\u201c und rufen im Kontextmen\u00fc Project auf; alternativ im Men\u00fcpunkt Project > Properties oder \u00fcber die Tastenkombination Alt + Return. Im Dialog navigiere links auf Java Build Path und aktiviere den Reiter Projects. W\u00e4hle Add\u2026 und im Dialog w\u00e4hle aus der Liste com.tutego.greeter. Ok schlie\u00dft den kleinen Dialog und unter Required projects in build path taucht eine Abh\u00e4ngigkeit auf.<\/p>\n
Wir k\u00f6nnen jetzt zwei einfache Klassen implementieren. Zun\u00e4chst f\u00fcr das Projekt \u201ecom.tutego.greeter\u201c:<\/p>\n
com\/tutego\/insel\/greeter\/Greeter.java<\/p>\n
package com.tutego.insel.greeter;<\/p>\n
public class Greeter {<\/p>\n
private Greeter() { }<\/p>\n
public static Greeter instance() {<\/p>\n
return new Greeter();<\/p>\n
}<\/p>\n
public void greet( String name ) {<\/p>\n
System.out.println( "Hey "+ name );<\/p>\n
}<\/p>\n
}<\/p>\n
Und die Hauptklasse im Projekt \u201ecom.tutego.main\u201c:<\/p>\n
com\/tutego\/insel\/main\/Main<\/p>\n
package com.tutego.insel.main;<\/p>\n
import com.tutego.insel.greeter.Greeter;<\/p>\n
public class Main {<\/p>\n
public static void main( String[] args ) {<\/p>\n
Greeter.instance().greet( "Chris" );<\/p>\n
}<\/p>\n
}<\/p>\n
Da wir in Eclipse vorher die Abh\u00e4ngigkeit gesetzt haben, gibt es keinen Compilerfehler.<\/p>\n
Die Modulinformationen werden \u00fcber eine Datei module-info.java (kurz Modulinfodatei) deklariert, Annotationen kommen nicht zum Einsatz. Diese zentrale Datei ist der Hauptunterschied zwischen einem Modul und einer einfachen JAR-Datei. In dem Moment, in dem die spezielle Klassendatei module-info.class im Modulpfad ist, beginnt die Laufzeitumgung das Projekt als Modul zu interpretieren.<\/p>\n
Testen wir das, indem wir in unsere Projekte \u201ecom.tutego.greeter\u201c und \u201ecom.tutego.main\u201c eine Modulinfodatei anlegen. Das kann Eclipse \u00fcber das Kontextmen\u00fc Configue > Create module-info.java f\u00fcr uns machen.<\/p>\n
F\u00fcr das erste Modul com.tutego.greeter entsteht:<\/p>\n
module-info.java<\/p>\n
\/**<\/p>\n
* <\/p>\n
*\/<\/p>\n
\/**<\/p>\n
* @author Christian<\/p>\n
*<\/p>\n
*\/<\/p>\n
module com.tutego.greeter {<\/p>\n
exports com.tutego.insel.greeter;<\/p>\n
requires java.base;<\/p>\n
}<\/p>\n
Und f\u00fcr die zweite Modulinfodatei \u2013 Kommentare ausgeblendet:<\/p>\n
module-info.java<\/p>\n
module com.tutego.main {<\/p>\n
exports com.tutego.insel.main;<\/p>\n
requires com.tutego.greeter;<\/p>\n
requires java.base;<\/p>\n
}<\/p>\n
Hinter dem Schl\u00fcsselwort module steht der Name des Moduls, den Eclipse automatisch so w\u00e4hlt wie das Eclipse-Projekt hei\u00dft.[1]<\/a> Es folgt ein Block in geschweiften Klammern.<\/p>\n Zwei Schl\u00fcsselworte fallen ins Auge, die wir schon vorher bemerkt haben: exports und requires.<\/p>\n \u00b7 Das Projekt\/Modul com.tutego.greeter exportiert das Paket com.tutego.insel.greeter. Andere Pakete nicht. Es ben\u00f6tigt (requires) java.base, wobei das Modul Standard ist, und die Zeile gel\u00f6scht werden kann.<\/p>\n \u00b7 Das Projekt\/Modul com.tutego.main exportiert das Paket com.tutego.insel.main und es ben\u00f6tigt com.tutego.greeter \u2013 diese Information nimmt sich Eclipse selbstst\u00e4ndig aus den Projektabh\u00e4ngigkeiten.<\/p>\n Info: Ein Modul required ein anderes Modul aber exports ein Paket.<\/strong><\/p>\n Beginnen wir mit den Experimenten in den beiden module-info.java-Dateien: <\/p>\n Modul<\/p>\n<\/td>\n Aktion<\/p>\n<\/td>\n Ergebnis<\/p>\n<\/td>\n<\/tr>\n com.tutego.greeter<\/p>\n com.tutego.main<\/p>\n<\/td>\n \/\/ requires java.base;<\/p>\n<\/td>\n Auskommentieren f\u00fchrt zu keiner \u00c4nderung, da java.base immer required wird<\/p>\n<\/td>\n<\/tr>\n com.tutego.greeter<\/p>\n<\/td>\n \/\/ exports com.tutego.insel.greeter;<\/p>\n<\/td>\n Compilerfehler im main-Modul \u201cThe type com.tutego.insel.greeter.Greeter is not accessible\u201d<\/p>\n<\/td>\n<\/tr>\n com.tutego.greeter<\/p>\n<\/td>\n exports com.tutego.insel.greeter to god;<\/p>\n<\/td>\n Nur das Modul god bekommt Zugriff auf com.tutego.insel.greeter. Das main-Modul meldet \u201cThe type com.tutego.insel.greeter.Greeter is not accessible\u201d<\/p>\n<\/td>\n<\/tr>\n com.tutego.greeter<\/p>\n<\/td>\n exports com.tutego.insel.closer;<\/p>\n<\/td>\n Hinzuf\u00fcgen f\u00fchrt zum Compilerfehler \u201cThe package com.tutego.insel.closer does not exist or is empty\u201d<\/p>\n<\/td>\n<\/tr>\n com.tutego.main<\/p>\n<\/td>\n \/\/ requires com.tutego.greeter;<\/p>\n<\/td>\n Compilerfehler \u201cThe import com.tutego.insel.greeter cannot be resolved\u201d<\/p>\n<\/td>\n<\/tr>\n com.tutego.main<\/p>\n<\/td>\n \/\/ exports com.tutego.insel.main;<\/p>\n<\/td>\n Keins, denn c.t.i.m wird von keinem Modul required<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Die Zeile mit exports com.tutego.insel.greeter to god zeigt einen qualifizierten Export.<\/p>\n Setzen wir in der Wurzelverzeichnis vom Modul com.tutego.greeter ein Batch-Skript compile.bat:<\/p>\n compile.bat<\/p>\n set PATH=%PATH%;C:\\Program Files\\Java\\jdk-9\\bin<\/p>\n rmdir \/s \/q lib<\/p>\n mkdir lib<\/p>\n javac -d bin src\\module-info.java src\\com\\tutego\\insel\\greeter\\Greeter.java<\/p>\n jar –create –file=lib\/com.tutego.greeter@1.0.jar –module-version=1.0 -C bin .<\/p>\n jar –describe-module –file=lib\/com.tutego.greeter@1.0.jar<\/p>\n Folgende Schritte f\u00fchrt das Skript aus:<\/p>\n 1. Setzen der PATH-Variable f\u00fcr die JDK-Tools<\/p>\n 2. L\u00f6schen eines vielleicht schon angelegten lib-Ordners<\/p>\n 3. Anlegen eines neuen lib-Orders f\u00fcr die JAR-Datei<\/p>\n 4. \u00dcbersetzen der zwei Java-Dateien in den Zielordner bin<\/p>\n 5. Anlegen einer JAR-Datei. –create (abk\u00fcrzbar zu \u2013c) instruiert das Werkzeug eine neue JAR-Datei anzulegen. \u2013file (oder kurz \u2013f) bestimmt den Zielnamen. \u2013module-version unsere Versionsnummer und \u2013C wechselt das Verzeichnis und beginnt ab dort die Dateien einzusammeln. Die Kommandozeilensyntax beschreibt Oracle auf der Webseite https:\/\/docs.oracle.com\/javase\/9\/tools\/jar.htm.<\/p>\n 6. Die Option –describe-module (oder kurz \u2013d) zeigt die Modulinformation und f\u00fchrt zu folgender (vereinfachten) Ausgabe: com.tutego.greeter@1.0 jar:file:\/\/\/C:\/\u2026\/com.tutego.greeter\/lib\/com.tutego.greeter@1.0.jar\/!module-info.class exports com.tutego.insel.greeter requires java.base.<\/p>\n F\u00fcr das zweite Projekt ist die compile.bat sehr \u00e4hnlich, dazu kommt ein Aufruf der JVM, um das Programm zu starten.<\/p>\n compile.bat<\/p>\n set PATH=%PATH%;C:\\Program Files\\Java\\jdk-9\\bin<\/p>\n rmdir \/s \/q lib<\/p>\n mkdir lib<\/p>\n javac -d bin –module-path ..\\com.tutego.greeter\\lib src\\module-info.java src\\com\\tutego\\insel\\main\\Main.java<\/p>\n jar -c -f=lib\/com.tutego.main@1.0.jar –main-class=com.tutego.insel.main.Main –module-version=1.0 -C bin .<\/p>\n java -p lib;..\\com.tutego.greeter\\lib -m com.tutego.main<\/p>\n \u00c4nderungen gegen\u00fcber dem ersten Skript sind:<\/p>\n 1. Beim Compilieren m\u00fcssen wir den Modulpfad mit –module-path (oder k\u00fcrzer mit -p) angeben, weil ja das Modul com.tutego.greeter required ist.<\/p>\n 2. Beim Anlegen der JAR-Datei geben wir \u00fcber \u2013main-class die Klasse mit der main(\u2026)-Methode an.<\/p>\n 3. Startet die JVM das Programm, l\u00e4dt sie das Hauptmodul und alle abh\u00e4ngigen Module. Wir geben beide lib-Order mit den JAR-Dateien an und mit \u2013m das sogenannte initiale Modul f\u00fcr die Hauptklasse.<\/p>\n JAR-Dateien spielen seit 20 Jahren eine zentrale Rolle im Java-System; sie vom einen zum anderen Tag abzuschaffen w\u00fcrde gro\u00dfe Probleme bereiten. Ein Blick auf https:\/\/mvnrepository.com\/repos offenbart \u00fcber 7,7 Millionen Artefakte; es gehen auch Dokumentationen und andere Dateien in die Statistik ein, doch es gibt eine Gr\u00f6\u00dfenordnung, wie viele JAR-Dateien im Umlauf sind.<\/p>\n Damit JAR-Dateien unter Java 9 eingebracht werden k\u00f6nnen gibt es zwei L\u00f6sungen: das JAR in den Klassenpfad oder in den neuen Modulpfad zu setzen. Kommt ein JAR in den Modulpfad und hat es keine Modulinfodatei entsteht ein automatisches Modul. Bis auf eine kleine Einschr\u00e4nkung funktioniert das f\u00fcr die meisten existierenden Java-Bibliotheken.<\/p>\n Ein automatisches Modul hat gewisse Eigenschaften f\u00fcr den Modulnamen und Konsequenzen in den Abh\u00e4ngigkeiten:<\/p>\n \u00b7 Ohne Modulinfo haben die automatischen Module keinen selbstgew\u00e4hlten Namen, sondern sie bekommen vom System einen Namen zugewiesen, der sich aus dem Dateinamen ergibt.[2]<\/a> Vereinfacht gesagt: Angeh\u00e4ngte Versionsnummern und die Dateiendung werden entfernt und alle nicht-alphanummerischen Zeichen durch Punkte ersetzt, jedoch nicht zwei Punkte hintereinander.[3]<\/a> Die Version wird erkannt. Die Dokumentation gibt das Beispiel foo-bar-1.2.3-SNAPSHOT.jar an, was zum Modulnamen foo.bar und der Version 1.2.3-SNAPSHOT f\u00fchrt.<\/p>\n \u00b7 Automatische Module exportieren immer alle ihre Pakete. Wenn es also eine Abh\u00e4ngigkeit zu diesem automatischen Modul gibt kann der Bezieher alle sichtbare Typen und Eigenschaften verwenden.<\/p>\n \u00b7 Automatische Module k\u00f6nnen alle anderen Module lesen, auch die unbenannten.<\/p>\n Auf den ersten Blick scheint eine Migration in Richtung Java 9 einfach: Alle JARs auf den Modulpfad und nacheinander Modulinfodateien anlegen. Allerdings gibt es JAR-Dateien, die von der JVM als automatisches Modul abgelehnt werden, wenn sie n\u00e4mlich Typen eines Paketes enthalten, und dieses Paket sich schon in einem anderen aufgenommen Modul befindet. Module d\u00fcrfen keine \u201esplit packages\u201c enthalten, also das gleiche Paket noch einmal enthalten. Die Migration erfordert dann entweder a) das Zusammenlegen der Pakete zu einem Modul, b) die Verschiebung in unterschiedliche Pakete oder c) die Nutzung des Klassenpfades<\/p>\n Eine Migration auf eine neue Java-Version sieht in der Regel so aus, dass zuerst die JVM gewechselt und gepr\u00fcft wird, ob die vorhandene Software weiterhin funktioniert. Laufen die Testf\u00e4lle durch und gibt es keine Auff\u00e4lligkeiten im Testbetrieb kann der Produktivbetrieb unter der neuen Version erfolgen. Gibt es keine Probleme, k\u00f6nnen nach einiger Zeit die neuen Sprachmittel und Bibliotheken verwendet werden.<\/p>\n \u00dcbertragen wir das auf den Wechsel von Java 8 auf Java 9: Eine vorhandene Java-Software muss inklusive aller Einstellungen und Eintr\u00e4ge im Klassenpfad weiterhin laufen. Das hei\u00dft, eine Java 9 Laufzeitumgebung kann den Klassenpfad nicht ignorieren. Da es intern nur einen Modulpfad gibt, m\u00fcssen auch diese JAR-Dateien zu Modulen werden. Die L\u00f6sung ist das unbenannte Modul (eng. unnamed module): jedes JAR im Klassenpfad \u2013 dabei spielt es keine Rolle, ob es eine modul-info.class enth\u00e4lt \u2013 kommt in das unbenannte Modul. Davon gibt es nur eines, wir sprechen also im Singular, nicht Plural.<\/p>\n \u201eUnbenannt\u201c sagt schon, dass das Modul keinen Namen hat, und folglich auch keine Abh\u00e4ngigkeit zu den JAR-Dateien im unbenannten Modul existieren kann; das ist der Unterschied zu einem automatischen Modul. Ein unbenanntes Modul hat die gleiche Eigenschaft wie ein automatisches Modul, dass es alle Pakete exportiert. Und weil es zur Migration geh\u00f6rt, hat ein unbenanntes Modul auch Zugriff auf alle anderen Module.<\/p>\n Die Laufzeitumgebung sortiert Module in einem Graphen ein. Die Abh\u00e4ngigkeit der Module f\u00fchrt dabei zu sogenannten Lesbarkeit (engl. readibility): Ben\u00f6tigt Modul A das Modul B, so ist liest A das Modul B und B wird von A gelesen. F\u00fcr die Funktionsweise vom Modulsystem ist dies elementar, denn so werden zur \u00dcbersetzungszeit schon Fehler ausgeschlossen, wie Zkylen, oder gleiche Pakete in unterschiedlichen Modulen. Die Lesbarkeit ist zentral f\u00fcr eine zuverl\u00e4ssige Konfiguration, engl. reliable configuration.<\/p>\n Ein Schritt weiter geht der Begriff der Erreichbarkeit\/Zug\u00e4nglichkeit (engl. accessibility). Wenn ein Modul ein anderes Modul grunds\u00e4tzlich lesen kann, bedeutet es noch nicht, dass es an alle Pakete und Typen kommt, denn nur die Typen sind sichtbar, die exportiert worden. Lesbare und erreichbare Typen nennen sich erreichbar.<\/p>\n Die n\u00e4chste Frage ist, welcher Modultyp auf welchen anderen Modultyp Zugriff hat. Eine Tabelle fasst die Lesbarkeit am Besten zusammen: <\/p>\n Modultyp<\/p>\n<\/td>\n Ursprung<\/p>\n<\/td>\n Exportiert Pakete<\/p>\n<\/td>\n Hat Zugriff auf<\/p>\n<\/td>\n<\/tr>\n Plattformmodul<\/p>\n<\/td>\n JDK<\/p>\n<\/td>\n explizit<\/p>\n<\/td>\n Benannte Module<\/p>\n<\/td>\n Container mit Modulinfo im Modulpfad<\/p>\n<\/td>\n explizit<\/p>\n<\/td>\n Plattformmodule, andere benannte Module, automatische Module<\/p>\n<\/td>\n<\/tr>\n Automatische Module<\/p>\n<\/td>\n Container ohne Modulinfo im Modulpfad<\/p>\n<\/td>\n alle<\/p>\n<\/td>\n Plattformmodule, andere benannte Module, automatische Module, unbenanntes Modul<\/p>\n<\/td>\n<\/tr>\n Unbenanntes Modul<\/p>\n<\/td>\n Klassendateien und JARs im Klassenpfad <\/p>\n<\/td>\n alle<\/p>\n<\/td>\n Plattformmodule, benannte Module, automatische Module<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Der Modulinfodatei kommt dabei die gr\u00f6\u00dfte Bedeutung zu, denn sie macht aus einer JAR ein modular-JAR; fehlt die Modulinfomation bleibt es eine normale JAR, wie sie Java-Entwickler seit 20 Jahren kennen. Die JAR-Datei kann neu in den Modulpfad kommen oder in den bekannten Klassenpfad. Das ergibt vier Kombinationen: <\/p>\n Modulpfad<\/p>\n<\/td>\n Klassenpfad<\/p>\n<\/td>\n<\/tr>\n JAR mit Modulinfomation<\/p>\n<\/td>\n wird benanntes Module<\/p>\n<\/td>\n wird ubenanntes Modul<\/p>\n<\/td>\n<\/tr>\n JAR ohne Modulinfomation<\/p>\n<\/td>\n wird automatisches Modul<\/p>\n<\/td>\n wird unbenanntes Modul<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n JARs im Pfad<\/p>\n JAR-Archive im Klassenpfad sind das bekannte Verhalten, weswegen auch ein Wechsel von Java 8 auf Java 9 m\u00f6glich sein sollte.<\/p>\n Nehmen wir an, unsere monolithische Applikation hat keine Abh\u00e4ngigkeiten zu externen Bibliotheken und soll modularisiert werden. Dann besteht der erste Schritt darin, die gesamte Applikation in ein gro\u00dfes benanntes Modul zu setzen. Als n\u00e4chstes m\u00fcssen die einzelnen Bereiche identifiziert werden, damit nach und nach die Bausteine in einzelne Module wandern. Das ist nicht immer einfach, zumal zyklische Abh\u00e4ngigkeiten nicht unwahrscheinlich sind. Bei der Modularisierung des JDK hatten die Oracle-Entwickler viel M\u00fche.<\/p>\n Traditionell generieren Build-Werkzeuge wie Maven oder Gradle JAR-Dateien und ein Dateiname hat sich irgendwie ergeben. Werden jedoch diese JAR-Dateien zu automatischen Modulen spielt der Dateiname pl\u00f6tzlich eine gro\u00dfe Rolle. Doch bewusst wurde der Dateiname vermutlich nie gew\u00e4hlt. Referenziert ein benanntes Modul ein automatisches Modul bringt das zwei Probleme mit sich: \u00c4ndert sich der Dateiname, lassen wir die Versionsnummer einmal au\u00dfen vor, hei\u00dft auch das automatische Module anders, und die Abh\u00e4ngigkeit kann nicht mehr aufgel\u00f6st werden. Das zweite Problem ist gr\u00f6\u00dfer. Viele Java-Bibliotheken haben noch keine Modulinformationen, und folglich werden Entwickler eine Abh\u00e4ngigkeit zu diesem automatischen Modul \u00fcber den abgeleiteten Namen ausdr\u00fccken. Nehmen wir z. B. die beliebte Open-Source Bibliothek Google Guava. Die JAR-Datei hat den Dateinamen guava-23.0.jar \u2013 guava hei\u00dft folglich das automatische Modul. Ein benanntes Modul (nennen wir es M1) kann \u00fcber required guava eine Abh\u00e4ngigkeit ausdr\u00fccken. Konvertiert Google die Bibliothek in ein echtes Java 9-Modul, dann wird sich der Name \u00e4ndern \u2013 geplant ist com.google.guava. Und \u00e4ndert sich der Name, f\u00fchren alle Referenzierungen in Projekten zu einem Compilerfehler; ein Alias w\u00e4re eine tolle Idee, das gibt es jedoch nicht. Und das Problem besteht ja nicht nur im eigenen Code der Guava referenziert; Referenziert das eigene Modul M1 ein Modul M2, das wiederum Guava referenziert, so gibt es das gleiche Problem \u2013 wir sprechen von einer transitiven Abh\u00e4ngigkeit. Die \u00c4nderung vom Modulnamen von Guava wird zum Problem, denn wir m\u00fcssen warten, bis M2 den Namen korrigiert, damit M1 wieder g\u00fcltig ist.<\/p>\n Eine L\u00f6sung mildert das Problem ab: In der JAR-Manifest-Datei kann ein Eintrag Automatic-Module-Name gesetzt werden \u2013 das \u201e\u00fcberschreibt\u201c den automatischen Modulnamen.<\/p>\n Beispiel: Apache Commons setzt den Namen so:<\/strong><\/p>\n Automatic-Module-Name: org.apache.commons.lang3<\/strong><\/p>\n Benannte Module, die Abh\u00e4ngigkeiten auf automatische Module besitzen, sind also ein Problem. Es ist zu hoffen, dass die zentralen Java-Bibliotheken, auf die sich so viele L\u00f6sungen st\u00fctzen, schnell Modulinformationen einf\u00fchren. Das w\u00e4re eine L\u00f6sung von unten nach oben, englisch Bottom-Up. Das ist das einzige, was erfolgversprechend ist, aber wohl auch eine lange Zeit ben\u00f6tigen wird. Im Monat vom Java 9-Release hat noch keine wichtige Java-Bibliothek eine Modulinformation, Automatic-Module-Name kommt h\u00e4ufiger vor.<\/p>\n [1]<\/a> Zur Benennung von Modulen gibt es Empfehlungen in dem englischsprachigen Beitrag http:\/\/mail.openjdk.java.net\/pipermail\/jpms-spec-experts\/2017-May\/000687.html<\/p>\n\n\n
\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \u00dcbersetzen und Packen von der Kommandozeile<\/h3>\n
Automatische Module<\/h3>\n
Unbenanntes Modul<\/h3>\n
Lesbarkeit und Zugreifbarkeit<\/h3>\n
\n\n
\n \n \n \n \n \n \n \n \n <\/td>\n<\/tr>\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n Lesbarkeit der Module<\/h3>\n
\n\n
\n <\/td>\n \n \n \n \n \n \n \n \n \n \n Modul-Migration<\/h3>\n
Das Problem mit automatischen Modulen<\/h3>\n
\n