Mit Java 9 wird eine neue Abstraktionsebene über Paketen eingeführt, die formal als Java Platform Module System (JPMS) oder kurz „Module“ bezeichnet wird.
In diesem Tutorial werden wir das neue System durchgehen und seine verschiedenen Aspekte diskutieren.
Wir werden auch ein einfaches Projekt erstellen, um alle Konzepte zu demonstrieren, die wir in diesem Handbuch lernen werden.
2. Was ist ein Modul?
Zunächst müssen wir verstehen, was ein Modul ist, bevor wir verstehen können, wie man sie verwendet.
Ein Modul ist eine Gruppe eng verwandter Pakete und Ressourcen zusammen mit einer neuen Moduldeskriptordatei.
Mit anderen Worten, es handelt sich um eine "Paket mit Java-Paketen" -Abstraktion, mit der wir unseren Code noch wiederverwendbarer machen können.
2.1. Pakete
Die Pakete in einem Modul sind identisch mit den Java-Paketen, die wir seit der Einführung von Java verwenden.
Wenn wir ein Modul erstellen,we organize the code internally in packages just like we previously did with any other project.
Neben der Organisation unseres Codes werden Pakete verwendet, um zu bestimmen, welcher Code außerhalb des Moduls öffentlich zugänglich ist. Wir werden später in diesem Artikel mehr Zeit damit verbringen, darüber zu sprechen.
2.2. Ressourcen
Jedes Modul ist für seine Ressourcen wie Medien oder Konfigurationsdateien verantwortlich.
Zuvor haben wir alle Ressourcen in die Stammebene unseres Projekts gestellt und manuell verwaltet, welche Ressourcen zu verschiedenen Teilen der Anwendung gehörten.
Mit Modulen können wir die erforderlichen Bilder und XML-Dateien mit dem Modul liefern, das sie benötigt, wodurch die Verwaltung unserer Projekte erheblich vereinfacht wird.
2.3. Modulbeschreibung
Wenn wir ein Modul erstellen, fügen wir eine Deskriptordatei hinzu, die verschiedene Aspekte unseres neuen Moduls definiert:
Name - der Name unseres Moduls
Dependencies - Eine Liste anderer Module, von denen dieses Modul abhängt
Public Packages - Eine Liste aller Pakete, auf die von außerhalb des Moduls zugegriffen werden soll
Services Offered - Wir können Service-Implementierungen bereitstellen, die von anderen Modulen verwendet werden können
Services Consumed - Ermöglicht dem aktuellen Modul, Verbraucher eines Dienstes zu sein
Reflection Permissions - Ermöglicht anderen Klassen explizit die Verwendung von Reflection, um auf die privaten Mitglieder eines Pakets zuzugreifen
Die Regeln für die Modulbenennung ähneln denen für die Benennung von Paketen (Punkte sind zulässig, Bindestriche nicht). Es ist sehr üblich, Namen im Projektstil (my.module) oder im Reverse-DNS-Stil (com.example.mymodule) zu verwenden. In diesem Handbuch wird der Projektstil verwendet.
Wir müssen alle Pakete auflisten, die öffentlich sein sollen, da standardmäßig alle Pakete modulprivat sind.
Gleiches gilt für die Reflexion. Standardmäßig können wir keine Reflektion für Klassen verwenden, die wir aus einem anderen Modul importieren.
Später in diesem Artikel werden Beispiele für die Verwendung der Moduldeskriptordatei vorgestellt.
2.4. Modultypen
Es gibt vier Arten von Modulen im neuen Modulsystem:
System Modules– Dies sind die Module, die aufgelistet werden, wenn wir den obigen Befehllist-modules ausführen. Dazu gehören die Java SE- und JDK-Module.
Application Modules - Diese Module möchten wir normalerweise erstellen, wenn wir uns für die Verwendung von Modulen entscheiden. Sie werden in der kompiliertenmodule-info.class-Datei benannt und definiert, die in der zusammengestellten JAR enthalten ist.
Automatic Modules - Wir können inoffizielle Module einschließen, indem wir dem Modulpfad vorhandene JAR-Dateien hinzufügen. Der Name des Moduls wird vom Namen der JAR abgeleitet. Automatische Module haben vollen Lesezugriff auf alle anderen vom Pfad geladenen Module.
Unnamed Module - Wenn eine Klasse oder JAR in den Klassenpfad geladen wird, jedoch nicht in den Modulpfad, wird sie automatisch dem unbenannten Modul hinzugefügt. Es ist ein Sammelmodul, um die Abwärtskompatibilität mit zuvor geschriebenem Java-Code aufrechtzuerhalten.
2.5. Verteilung
Module können auf zwei Arten verteilt werden: als JAR-Datei oder als „explodiertes“ kompiliertes Projekt. Dies ist natürlich dasselbe wie bei jedem anderen Java-Projekt, daher sollte es keine Überraschung sein.
Wir können Projekte mit mehreren Modulen erstellen, die aus einer „Hauptanwendung“ und mehreren Bibliotheksmodulen bestehen.
Wir müssen jedoch vorsichtig sein, da wir nur ein Modul pro JAR-Datei haben können.
Wenn wir unsere Build-Datei einrichten, müssen wir sicherstellen, dass jedes Modul in unserem Projekt als separate JAR-Datei gebündelt wird.
3. Standardmodule
Wenn wir Java 9 installieren, können wir sehen, dass das JDK jetzt eine neue Struktur hat.
Sie haben alle Originalverpackungen genommen und in das neue Modulsystem verschoben.
Wir können sehen, was diese Module sind, indem wir Folgendes in die Befehlszeile eingeben:
java --list-modules
Diese Module sind in vier Hauptgruppen unterteilt:java, javafx, jdk, andOracle.
java Module sind die Implementierungsklassen für die SE-Kernspezifikation.
javafx Module sind die FX UI-Bibliotheken.
Alles, was vom JDK selbst benötigt wird, wird in den Modulen vonjdkgespeichert.
Und schließlichanything that is Oracle-specific is in the oracle modules.
4. Moduldeklarationen
Um ein Modul einzurichten, müssen wir eine spezielle Datei im Stammverzeichnis unserer Pakete mit dem Namenmodule-info.java ablegen.
Diese Datei wird als Moduldeskriptor bezeichnet und enthält alle Daten, die zum Erstellen und Verwenden unseres neuen Moduls erforderlich sind.
Wir konstruieren das Modul mit einer Deklaration, deren Body entweder leer ist oder aus Moduldirektiven besteht:
module myModuleName {
// all directives are optional
}
Wir starten die Moduldeklaration mit dem Schlüsselwortmoduleund folgen dem mit dem Namen des Moduls.
Das Modul funktioniert mit dieser Deklaration, wir benötigen jedoch in der Regel weitere Informationen.
Hier kommen die Modulrichtlinien ins Spiel.
4.1. Benötigt
Unsere erste Direktive istrequires. Mit dieser Modulanweisung können Sie Modulabhängigkeiten deklarieren:
module my.module {
requires module.name;
}
Jetzt hatmy.moduleboth a runtime and a compile-time dependency aufmodule.name.
Und auf alle aus einer Abhängigkeit exportierten öffentlichen Typen kann unser Modul zugreifen, wenn wir diese Direktive verwenden.
4.2. Benötigt statisch
Manchmal schreiben wir Code, der auf ein anderes Modul verweist, den Benutzer unserer Bibliothek jedoch niemals verwenden möchten.
Beispielsweise könnten wir eine Utility-Funktion schreiben, die unseren internen Status schön druckt, wenn ein anderes Protokollierungsmodul vorhanden ist. Aber nicht jeder Verbraucher unserer Bibliothek möchte diese Funktionalität, und er möchte keine zusätzliche Protokollierungsbibliothek hinzufügen.
In diesen Fällen möchten wir eine optionale Abhängigkeit verwenden. Mit der Direktiverequires staticerstellen wir eine Abhängigkeit nur zur Kompilierungszeit:
module my.module {
requires static module.name;
}
4.3. Benötigt Transitiv
Wir arbeiten gewöhnlich mit Bibliotheken zusammen, um unser Leben zu erleichtern.
Wir müssen jedoch sicherstellen, dass jedes Modul, das unseren Code einbringt, auch diese zusätzlichen "transitiven" Abhängigkeiten einbringt, da sie sonst nicht funktionieren.
Glücklicherweise können wir dierequires transitive-Richtlinie verwenden, um nachgeschaltete Verbraucher zu zwingen, auch unsere erforderlichen Abhängigkeiten zu lesen:
Wenn ein Entwicklerrequires my.module hat, muss er nicht auchrequires module.name sagen, damit unser Modul noch funktioniert.
4.4. Exporte
By default, a module doesn’t expose any of its API to other modules. Diesesstrong encapsulation war einer der Hauptmotive für die Erstellung des Modulsystems.
Unser Code ist deutlich sicherer, aber jetzt müssen wir unsere API explizit für die Welt öffnen, wenn wir möchten, dass sie verwendet werden kann.
Wir verwenden die Direktiveexports, um alle öffentlichen Mitglieder des genannten Pakets verfügbar zu machen:
module my.module {
exports com.my.package.name;
}
Wenn jemandrequires my.module ausführt, hat er Zugriff auf die öffentlichen Typen in unseremcom.my.package.name-Paket, jedoch nicht auf ein anderes Paket.
4.5. Exporte… nach
Wir könnenexports…to verwenden, um unsere öffentlichen Klassen für die Welt zu öffnen.
Aber was ist, wenn nicht die ganze Welt auf unsere API zugreifen soll?
Mit der Direktiveexports…tokönnen wir einschränken, welche Module Zugriff auf unsere APIs haben.
Ähnlich wie bei der Direktiveexportsdeklarieren wir ein Paket als exportiert. Wir listen aber auch auf, welche Module wir dieses Paket alsrequires importieren dürfen. Mal sehen, wie das aussieht:
module my.module {
export com.my.package.name to com.specific.package;
}
4.6. Uses
Aservice ist eine Implementierung einer bestimmten Schnittstelle oder abstrakten Klasse, die von anderen Klassenconsumed sein kann.
Wir bezeichnen die Dienste, die unser Modul verbraucht, mit der Direktiveuses.
Beachten Sie, dassthe class name we use is either the interface or abstract class of the service, not the implementation class:
module my.module {
uses class.name;
}
Wir sollten hier beachten, dass es einen Unterschied zwischen derrequires-Richtlinie und deruses-Richtlinie gibt.
Möglicherweise istrequireein Modul, das einen Dienst bereitstellt, den wir verwenden möchten, aber dieser Dienst implementiert eine Schnittstelle aus einer seiner transitiven Abhängigkeiten.
Anstatt unser Modul zu zwingen, für alle Fälle die transitiven Abhängigkeiten vonallzu erfordern, verwenden wir die Direktiveuses, um die erforderliche Schnittstelle zum Modulpfad hinzuzufügen.
4.7. Bietet ... Mit
Ein Modul kann auch einservice provider sein, das andere Module verbrauchen können.
Der erste Teil der Direktive ist das Schlüsselwortprovides. Hier setzen wir die Schnittstelle oder den abstrakten Klassennamen.
Als nächstes haben wir die Direktivewith, in der wir den Namen der Implementierungsklasse angeben, der entwederimplementsdie Schnittstelle oderextendsdie abstrakte Klasse ist.
So sieht es zusammen aus:
module my.module {
provides MyInterface with MyInterfaceImpl;
}
4.8. Open
Wir haben bereits erwähnt, dass die Kapselung eine treibende Kraft für den Entwurf dieses Modulsystems darstellt.
Vor Java 9 war es möglich, mithilfe von Reflection jeden Typ und jedes Element in einem Paket zu untersuchen, auch dieprivate. Nichts wurde wirklich gekapselt, was den Entwicklern der Bibliotheken alle möglichen Probleme bereiten kann.
Da Java 9strong encapsulation,we now have to explicitly grant permission for other modules to reflect on our classes. erzwingt
Wenn wir weiterhin die vollständige Reflexion zulassen möchten, wie dies bei älteren Java-Versionen der Fall war, können wir einfachopendas gesamte Modul einrichten:
open module my.module {
}
4.9. Öffnet
Wenn wir die Reflektion privater Typen zulassen müssen, aber nicht möchten, dass unser gesamter Code verfügbar gemacht wird,we can use the opens directive to expose specific packages.
Aber denken Sie daran, dies wird das Paket für die ganze Welt öffnen. Stellen Sie also sicher, dass dies das ist, was Sie wollen:
module my.module {
opens com.my.package;
}
4.10. Öffnet… bis
Okay, Reflexion ist manchmal großartig, aber wir wollen immer noch so viel Sicherheit, wie wir vonencapsulation bekommen können. We can selectively open our packages to a pre-approved list of modules, in this case, using the opens…to directive:
module my.module {
opens com.my.package to moduleOne, moduleTwo, etc.;
}
5. Befehlszeilenoptionen
Inzwischen wurde Maven und Gradle um die Unterstützung von Java 9-Modulen erweitert, sodass Sie Ihre Projekte nicht mehr manuell erstellen müssen. Es ist jedoch immer noch wertvoll,how zu kennen, um das Modulsystem über die Befehlszeile zu verwenden.
Wir werden die Befehlszeile für unser vollständiges Beispiel unten verwenden, um die Funktionsweise des gesamten Systems in unseren Köpfen zu festigen.
module-path– Wir verwenden die Option–module-path, um den Modulpfad anzugeben. Dies ist eine Liste von einem oder mehreren Verzeichnissen, die Ihre Module enthalten.
add-reads - Anstatt sich auf die Moduldeklarationsdatei zu verlassen, können wir das Befehlszeilenäquivalent der Direktiverequires verwenden. –add-reads.
add-exports– Befehlszeilenersatz für die Direktiveexports.
add-opens– Ersetzen Sie dieopen-Klausel in der Moduldeklarationsdatei.
add-modules– Fügt die Liste der Module dem Standardsatz von Modulen hinzu
list-modules– Druckt eine Liste aller Module und ihrer Versionszeichenfolgen
patch-module - Klassen in Modulen hinzufügen oder überschreiben
illegal-access=permit|warn|deny - Lockern Sie entweder die starke Kapselung, indem Sie eine einzelne globale Warnung anzeigen, jede Warnung anzeigen oder schlagen Sie mit Fehlern fehl. Der Standardwert istpermit.
6. Sichtweite
Wir sollten uns ein wenig mit der Sichtbarkeit unseres Codes befassen.
A lot of libraries depend on reflection to work their magic (JUnit und Spring kommen in den Sinn).
Standardmäßig haben wir in Java 9onlyZugriff auf öffentliche Klassen, Methoden und Felder in unseren exportierten Paketen. Selbst wenn wir Reflection verwenden, um Zugriff auf nicht öffentliche Mitglieder zu erhalten undsetAccessible(true), we anrufen, können wir nicht auf diese Mitglieder zugreifen.
Wir können die Optionenopen,opens undopens…toverwenden, um nur zur Laufzeit Zugriff für die Reflexion zu gewähren. Beachten Sie,this is runtime-only!
Wir werden nicht in der Lage sein, gegen private Typen zu kompilieren, und wir sollten es sowieso nie brauchen.
Wenn wir zur Reflexion Zugriff auf ein Modul haben müssen und nicht der Eigentümer dieses Moduls sind (dh wir können die Direktiveopens…tonicht verwenden), ist es möglich, die Befehlszeile–add-openszu verwenden. s Option, um eigenen Modulen zur Laufzeit den Reflexionszugriff auf das gesperrte Modul zu ermöglichen.
Die einzige Einschränkung besteht darin, dass Sie Zugriff auf die Befehlszeilenargumente benötigen, mit denen ein Modul ausgeführt wird, damit dies funktioniert.
7. Alles zusammenfügen
Nachdem wir nun wissen, was ein Modul ist und wie man es verwendet, erstellen wir ein einfaches Projekt, um alle Konzepte zu demonstrieren, die wir gerade gelernt haben.
Um die Dinge einfach zu halten, werden wir weder Maven noch Gradle verwenden. Stattdessen verlassen wir uns beim Erstellen unserer Module auf die Befehlszeilentools.
7.1. Einrichten unseres Projekts
Zuerst müssen wir unsere Projektstruktur einrichten. Wir erstellen mehrere Verzeichnisse, um unsere Dateien zu organisieren.
Beginnen Sie mit dem Erstellen des Projektordners:
mkdir module-project
cd module-project
Dies ist die Basis unseres gesamten Projekts. Fügen Sie hier also Dateien wie Maven- oder Gradle-Builddateien, andere Quellverzeichnisse und Ressourcen hinzu.
Wir haben auch ein Verzeichnis erstellt, in dem alle unsere projektspezifischen Module gespeichert sind.
Als nächstes erstellen wir ein Modulverzeichnis:
mkdir simple-modules
So wird unsere Projektstruktur aussehen:
module-project
|- // src if we use the default package
|- // build files also go at this level
|- simple-modules
|- hello.modules
|- com
|- example
|- modules
|- hello
|- main.app
|- com
|- example
|- modules
|- main
7.2. Unser erstes Modul
Nachdem wir die Grundstruktur eingerichtet haben, fügen wir unser erstes Modul hinzu.
Erstellen Sie im Verzeichnissimple-modules ein neues Verzeichnis mit dem Namenhello.modules.
We can name this anything we want but follow package naming rules (d. h. Perioden zum Trennen von Wörtern usw.). Wir können sogar den Namen unseres Hauptpakets als Modulnamen verwenden, aber normalerweise möchten wir uns an den gleichen Namen halten, den wir zum Erstellen einer JAR-Datei dieses Moduls verwenden würden.
In unserem neuen Modul können wir die gewünschten Pakete erstellen. In unserem Fall werden wir eine Paketstruktur erstellen:
com.example.modules.hello
Erstellen Sie als Nächstes eine neue Klasse mit dem NamenHelloModules.java in diesem Paket. Wir werden den Code einfach halten:
package com.example.modules.hello;
public class HelloModules {
public static void doSomething() {
System.out.println("Hello, Modules!");
}
}
Und schließlich fügen Sie im Stammverzeichnis vonhello.modulesunseren Moduldeskriptor hinzu. module-info.java:
Um dieses Beispiel einfach zu halten, exportieren wir lediglich alle öffentlichen Mitglieder descom.example.modules.hello -Spacks.
7.3. Unser zweites Modul
Unser erstes Modul ist großartig, aber es macht nichts.
Wir können ein zweites Modul erstellen, das es jetzt verwendet.
Erstellen Sie in unserem Verzeichnissimple-modules ein weiteres Modulverzeichnis mit dem Namenmain.app. Wir werden dieses Mal mit dem Modul-Deskriptor beginnen:
module main.app {
requires hello.modules;
}
Wir müssen nichts der Außenwelt aussetzen. Stattdessen müssen wir nur von unserem ersten Modul abhängen, damit wir Zugriff auf die öffentlichen Klassen haben, die es exportiert.
Jetzt können wir eine Anwendung erstellen, die es verwendet.
Erstellen Sie eine neue Paketstruktur:com.example.modules.main.
Erstellen Sie nun eine neue Klassendatei mit dem NamenMainApp.java.
package com.example.modules.main;
import com.example.modules.hello.HelloModules;
public class MainApp {
public static void main(String[] args) {
HelloModules.doSomething();
}
}
Und das ist alles, was wir brauchen, um Module zu demonstrieren. Der nächste Schritt besteht darin, diesen Code über die Befehlszeile zu erstellen und auszuführen.
7.4. Aufbau unserer Module
Um unser Projekt zu erstellen, können wir ein einfaches Bash-Skript erstellen und es im Stammverzeichnis unseres Projekts platzieren.
Erstellen Sie eine Datei mit dem Namencompile-simple-modules.sh:
Dieser Befehl besteht aus zwei Teilen, den Befehlenjavac undfind.
Der Befehlfind gibt einfach eine Liste aller.java-Dateien in unserem Verzeichnis für einfache Module aus. Diese Liste können wir dann direkt in den Java-Compiler einspeisen.
Das einzige, was wir anders als bei den älteren Java-Versionen tun müssen, ist die Angabe einesmodule-source-path-Parameters, um den Compiler darüber zu informieren, dass er Module erstellt.
Sobald wir diesen Befehl ausführen, haben wir einenoutDir-Ordner mit zwei kompilierten Modulen.
7.5. Ausführen unseres Codes
Und jetzt können wir endlich unseren Code ausführen, um zu überprüfen, ob die Module korrekt funktionieren.
Erstellen Sie eine weitere Datei im Stammverzeichnis des Projekts:run-simple-module-app.sh.
Wir verwenden diese Direktiven, um genauer zu bestimmen, wie unser Code verwendet werden soll.
Wir könnten die Implementierung in ein privates Paket packen und gleichzeitig die Schnittstelle in einem öffentlichen Paket verfügbar machen.
Dies macht unseren Code viel sicherer mit sehr wenig zusätzlichem Overhead.
Probieren Sie einige der anderen Anweisungen aus, um mehr über Module und deren Funktionsweise zu erfahren.
8. Hinzufügen von Modulen zum Unbenannten Modul
The unnamed module concept is similar to the default package. Daher wird es nicht als echtes Modul betrachtet, sondern kann als Standardmodul angesehen werden.
Wenn eine Klasse kein Mitglied eines benannten Moduls ist, wird sie automatisch als Teil dieses nicht benannten Moduls betrachtet.
Manchmal müssen wir dem Standardstammsatz Module hinzufügen, um bestimmte Plattform-, Bibliotheks- oder Dienstanbietermodule im Moduldiagramm sicherzustellen. Wenn wir beispielsweise versuchen, Java 8-Programme unverändert mit dem Java 9-Compiler auszuführen, müssen wir möglicherweise Module hinzufügen.
Im Allgemeinenthe option to add the named modules to the default set of root modules is *–add-modules <module>*(,<module>)*, wobei<module> ein Modulname ist.
Um beispielsweise Zugriff auf allejava.xml.bind Module zu gewähren, lautet die Syntax wie folgt:
--add-modules java.xml.bind
Um dies in Maven zu verwenden, können wir dasselbe inmaven-compiler-plugin einbetten:
In diesem umfangreichen Handbuch haben wir uns auf die Grundlagen des neuen Java 9-Modulsystems konzentriert und sie behandelt.
Wir haben zunächst darüber gesprochen, was ein Modul ist.
Als nächstes sprachen wir darüber, wie wir herausfinden können, welche Module im JDK enthalten sind.
Wir haben auch die Moduldeklarationsdatei ausführlich behandelt.
Wir haben die Theorie abgerundet, indem wir über die verschiedenen Befehlszeilenargumente gesprochen haben, die wir zum Erstellen unserer Module benötigen.
Schließlich haben wir unser gesamtes Vorwissen in die Praxis umgesetzt und eine einfache Anwendung erstellt, die auf dem Modulsystem aufbaut.