Nehmen wir aus Gründen der Argumentation an, dass Java 8 (und früher) bereits eine "Form" von Modulen (Jars) und Modulsystem (Klassenpfad) hat. Es gibt jedoch bekannte Probleme mit diesen.
Indem wir die Probleme untersuchen, können wir die Motivation für Jigsaw veranschaulichen. (Im Folgenden wird davon ausgegangen, dass wir keine OSGi, JBoss-Module usw. verwenden, die mit Sicherheit Lösungen bieten.)
Problem 1: Öffentlichkeit ist zu öffentlich
Betrachten Sie die folgenden Klassen (vorausgesetzt, beide sind öffentlich):
com.acme.foo.db.api.UserDao
com.acme.foo.db.impl.UserDaoImpl
Bei Foo.com entscheiden wir möglicherweise, dass unser Team verwenden UserDaound nicht UserDaoImpldirekt verwenden soll. Es gibt jedoch keine Möglichkeit, dies im Klassenpfad durchzusetzen.
In Jigsaw enthält ein Modul eine module-info.javaDatei, mit der wir explizit angeben können, was für andere Module öffentlich ist. Das heißt, die Öffentlichkeit hat Nuancen. Zum Beispiel:
module com.acme.foo.db {
exports com.acme.foo.db.api;
}
Problem 2: Reflexion ist ungezügelt
Angesichts der Klassen in # 1 könnte jemand dies in Java 8 noch tun:
Class c = Class.forName("com.acme.foo.db.impl.UserDaoImpl");
Object obj = c.getConstructor().newInstance();
Das heißt: Reflexion ist mächtig und wesentlich, aber wenn sie nicht aktiviert ist, kann sie verwendet werden, um auf unerwünschte Weise in die Interna eines Moduls zu gelangen. Mark Reinhold hat ein ziemlich alarmierendes Beispiel . (Der SO-Beitrag ist hier .)
In Jigsaw bietet eine starke Kapselung die Möglichkeit, den Zugriff auf eine Klasse einschließlich Reflexion zu verweigern. (Dies kann von den Befehlszeileneinstellungen abhängen, bis die überarbeitete technische Spezifikation für JDK 9 vorliegt.) Da Jigsaw für das JDK selbst verwendet wird, behauptet Oracle, dass das Java-Team dadurch die Plattforminternale schneller innovieren kann.
Problem 3: Der Klassenpfad löscht architektonische Beziehungen
Ein Team hat normalerweise ein mentales Modell für die Beziehungen zwischen Gläsern. Zum Beispiel foo-app.jarkann verwenden, foo-services.jarwelche Verwendungen foo-db.jar. Wir könnten behaupten, dass Klassen in foo-app.jar"die Serviceschicht" nicht umgehen und foo-db.jardirekt verwenden sollten. Es gibt jedoch keine Möglichkeit, dies über den Klassenpfad zu erzwingen. Mark Reinhold erwähnt dies hier .
Im Vergleich dazu bietet Jigsaw ein explizites, zuverlässiges Barrierefreiheitsmodell für Module.
Problem 4: monolithische Laufzeit
Die Java-Laufzeit ist monolithisch rt.jar. Auf meinem Computer sind es mehr als 60 MB mit 20.000 Klassen! In Zeiten von Mikrodiensten, IoT-Geräten usw. ist es unerwünscht, Corba, Swing, XML und andere Bibliotheken auf der Festplatte zu haben, wenn sie nicht verwendet werden.
Jigsaw unterteilt das JDK selbst in viele Module. zB java.sql enthält die bekannten SQL - Klassen. Dies hat mehrere Vorteile, aber ein neuer ist das jlinkWerkzeug. Angenommen, eine App ist vollständig modularisiert, jlinkwird ein verteilbares Laufzeit-Image generiert , das so beschnitten ist, dass es nur die angegebenen Module (und ihre Abhängigkeiten) enthält. Mit Blick auf die Zukunft sieht Oracle eine Zukunft vor, in der die JDK-Module vorab zu nativem Code kompiliert werden. Obwohl dies jlinkoptional ist und die AOT-Kompilierung experimentell ist, sind sie wichtige Hinweise darauf, wohin Oracle steuert.
Problem 5: Versionierung
Es ist bekannt, dass der Klassenpfad es uns nicht erlaubt, mehrere Versionen desselben JARs zu verwenden: zB bar-lib-1.1.jarund bar-lib-2.2.jar.
Jigsaw geht dieses Problem nicht an. Mark Reinhold gibt hier die Gründe an . Das Wesentliche ist, dass Maven, Gradle und andere Tools ein großes Ökosystem für das Abhängigkeitsmanagement darstellen und eine andere Lösung eher schädlich als nützlich ist.
Es sollte beachtet werden, dass andere Lösungen (z. B. OSGi) dieses Problem tatsächlich angehen (und andere, abgesehen von # 4).
Endeffekt
Das sind einige wichtige Punkte für Jigsaw, die durch spezifische Probleme motiviert sind.
Beachten Sie, dass das Erklären der Kontroverse zwischen Jigsaw-, OSGi-, JBoss-Modulen usw. eine separate Diskussion ist, die zu einer anderen Stack Exchange-Site gehört. Es gibt viel mehr Unterschiede zwischen den Lösungen als hier beschrieben. Darüber hinaus bestand ein ausreichender Konsens, um den Stimmzettel zur Überprüfung der öffentlichen Überprüfung für JSR 376 zu genehmigen .