9 kommt das lang angekündigte Modulsystem Jigsaw. Es ist eine grundlegende Strukturänderung von Java-Plattform und -Sprache, mit deren Auswirkungen man sich möglichst früh beschäftigen sollte. In diesem Tutorial erläutern wir die Grundlagen von Jigsaw und zeigen Motive und Ziele für die Einführung eines Modulsystems. Anhand von Code-Beispielen lernen die Teilnehmer, wie das Modulsystem aussieht und welche wichtigen Designentscheidungen getroffen wurden: Warum braucht Java überhaupt ein Modulsystem? Was will man erreichen? Wie profitieren Entwickler davon? Was ist ein Modul? Wie definiere ich Module und Abhängigkeiten? Welche Sichtbarkeiten gibt es zwischen Modulen? Module sind sowohl Compiler-Erweiterung als auch Teil des Laufzeitsystems. Wie wirkt sich das aus? Wie vertragen sich Module mit generischen Ansätzen wie Reflection oder Callbacks, auf denen eine Reihe bekannter Frameworks basieren? Welche anderen Konstrukte gibt es (Beispiel: Services)? Wie sehen Tools aus? IDE? Build/Dependency-Management? Wir bieten diese Einführung als Tutorial in Form eines interaktiven Entwicklerworkshops an. Wir zeigen die Grundlagen mit Folien und führen interaktiv durch Beispiele und Code, u.a. zu Module-Info, requires, exports, uses/provides, Interface/Implementierung, Exceptions, Reflection, Module-API und -Finder usw. Alle Beispiele können die Teilnehmer selber auf ihrem Laptop mitmachen und somit alles lokal nachvollziehen. Sourcecode und SEU/Entwicklungsumgebung mit JDK, Eclipse stellen wir zur Verfügung. Zielgruppe: Java-Entwickler, -Architekten (nur Basiskenntnisse von Java als Programmiersprache und als Ökosystem wie Tools, IDEs, Build-System erforderlich) Abstract JavaLand 2018 https://www.javaland.eu/de/programm/schulungstag/
Grammes, Accso - Accelerated Solutions GmbH Softwarearchitekt Dr. Rüdiger Grammes ist seit November 2011 als Principal bei der Accso – Accelerated Solutions GmbH und dort als Softwarearchitekt in verschiedenen Projekten unterwegs. [email protected] www.xing.com/profile/Ruediger_Grammes Martin Lehmann, Accso - Accelerated Solutions GmbH Cheftechnologe Martin Lehmann ist Diplom-Informatiker und arbeitet als Cheftechnologe und Softwarearchitekt bei der Accso - Accelerated Solutions GmbH. Seit Ende der 90er-Jahre wirkt er als Softwareentwickler und -architekt in der Softwareentwicklung in diversen Projekten der Individualentwicklung für Kunden verschiedener Branchen. Seit den Zeiten von Java 1.0 beschäftigt er sich mit Java als Programmiersprache und als Ökosystem. [email protected] @mrtnlhmnn www.xing.com/profile/Martin_Lehmann3 Dr. Kristine Schaal, Accso - Accelerated Solutions GmbH Softwarearchitektin Dr. Kristine Schaal ist als Softwarearchitektin bei der Accso - Accelerated Solutions GmbH tätig. Sie arbeitet seit fast 20 Jahren in der Softwareentwicklung und ist in Projekten der Individualentwicklung für Kunden verschiedener Branchen unterwegs, technisch überwiegend im Java-Umfeld. [email protected] @krschaal www.xing.com/profile/Kristine_Schaal
in Java 9: JSR 376 und seine Ziele Strong Encapsulation Eine Komponente kann ihr öffentliches API definieren und den Zugriff auf Implementierungsgeheimnisse verhindern. Reliable Configuration Ablösung des Classpath (fehleranfällig, wenn Klassen mehrfach enthalten sind Reihenfolge). Scalable Java SE Platform Die Java-Plattform selber ist nun modularisiert. Man kann individuell angepasste, „schlanke“ Plattformen bauen. JSR 376 (2014-2017) „Java Platform Module System“ (JPMS) Project Jigsaw in Java 9-Release vom 21. September 2017 enthalten. Aktuell: 9.0.4 vom 16. Januar 2018 Enthalten: JEP 261, 200, 201, 220, 260, 282 mit Modulsystem, modularisiertem JDK und der Kapselung interner APIs
Menge von Java-Packages & Resources Wird in ein „Modular JAR“ kompiliert. Dieses liegt im neuen Module-Path MP. Modul-Namen müssen eindeutig sein (erlaubt sind . und _ , aber nicht -) • „read“-Abhängigkeitsbeziehungen zu einem oder mehreren anderen Modulen • „exports“: Welche Packages des Moduls werden exportiert? (Default: nichts!) modmain Ein Modul ist ab Java 9 ein „First-Class-Citizen“ in Java. moda read exports pkg main pkg a pkga inter nal
Java 9: Readability und Accessibility read modmain pkg main Checks zu Compile-Zeit und zur Laufzeit von 1. neu: Readability „ich benötige dieses Modul, will darauf zugreifen“ 2. neu: Accessibility „worauf dürfen andere zugreifen?“ (unabhg. von Classloadern!) 3. Check der „alten“ Sichtbarkeitsmodifier public,protected,<package>,private de.my. package. ximpl de.my. package. internal de.my. package exports moda
pkga1/ A1.java pkga2/ A2.java pkga3/ A3.java pkgainternal/ InternalA.java modb/ module-info.java pkgb/ B.java modc/ module-info.java pkgc/ C.java modmain/ module-info.java pkgmain/ Main.java Modul-Definition eines Moduls liegt in Datei module-info.java im obersten Modul-Sourcenverzeichnis. • mit allen die Abhängigkeiten zu anderen Modulen • mit der Liste der zugreifbaren Packages Wird kompiliert zu .class-File! Wird mit in das JAR-File paketiert. Beispiel: Vier Module moda, modb, modc, modmain und ihr Sourcenbaum module-info.java
für optionale Abhängigkeiten module modmain { // Modul muss zur Compilezeit vorhanden sein // Zur Laufzeit ist das Modul optional requires static modb; } module modb { // requires static kann ebenfalls transitiv sein requires static transitive modc; } Optionale Abhängigkeiten werden zur Laufzeit nicht in den Modulgraph aufgenommen. Über den Launcher-Parameter --add-modules kann das Modul explizit aufgenommen werden.
java.sql.Driver Implementierung in Modul java.sql im MySQL-Driver Dynamische Bindung beim Start über ServiceLoader, also keine statische Auflösung über Modul-Namen wie bei Requires! Dynamische Bindung von Interface und Implementierung module java.sql { … // Definiert Schnittstelle uses java.sql.Driver; // ... und exportiert sie auch exports java.sql; } module com.mysql.jdbc { requires java.sql; … // Implementiert Schnittstelle provides java.sql.Driver with com.mysql.jdbc.Driver; }
eine Resource in einem anderen Modul moda: Kein Zugriff erlaubt? Stream ist null , keine IllegalAccessException Der Zugriff ist immer auch ohne opens möglich auf: • Resources im "unnamed package" • Resources, deren Verzeichnis sich nicht auf einen gültigen Packagenamen abbilden lässt (z.B. META-INF/MANIFEST.MF) Resource wird über ihr Verzeichnis geschützt, wenn sich dieses auf einen Package-Namen abbilden lässt. Das Package muss mit opens (nicht exports!) geöffnet sein. Der Zugriff auf Resources anderer Module ist geschützt! A.class.getModule().getResourceAsStream("/foo/bar.properties")
um Reflection? (und um Serialisierung, Dependency-Injection, Bytecode-Enhancement etc.) Zur Erinnerung 1. Check der Readability 2. Check der Accessibility 3. Check von public,protected,<package>,private Alle Checks auch bei Reflection! Convenience bei Reflection: read-Beziehung ist immer vorhanden. Aber Accessibility-Checks greifen auch „scharf“ bei Reflection: Klassen in nicht exportierten Packages sind also nicht zugreifbar. • Gilt für newInstance, getField, getMethod, … • Gilt auch für setAccessible(true)
für „Deep Reflection“ mit setAccessible(true) Shortcut „open module“ öffnet alle Packages des Moduls mit „opens“ opens öffnet ein Package nur zur Laufzeit Compile-Zeit Reflection (Shallow) Reflection (Deep) exports pkg erlaubt erlaubt nicht erlaubt opens pkg nicht erlaubt erlaubt erlaubt exports pkg und opens pkg erlaubt erlaubt erlaubt
immer um Typen-Sichtbarkeit: Interfaces exports pkga inter nal pkga Inte rnal Data Nur Export von IData Instanzen von InternalData behalten ihren Typ auch über Modulgrenze hinaus. public class Factory { public IData createData() { return new InternalData(); } … public class Caller { … IData myData = new Factory().createData(); … I Data Fact ory Call er mod main moda pkgmain
immer um Typen-Sichtbarkeit: Ableitung exports pkga inter nal pkga Inte rnal Data Nur Export von Data Instanzen von InternalData behalten ihren Typ auch über Modulgrenze hinaus. public class Factory { public Data createData() { return new InternalData(); } … public class Caller { … Data myData = new Factory().createData(); … Data Fact ory Call er moda mod main pkgmain
immer um Typen-Sichtbarkeit: Ableitung exports pkga inter nal pkga Inte rnal Data Caller kann nur Methoden von Data aufrufen, es werden aber die Implementierungen von InternalData benutzt. public class Factory { public Data createData() { return new InternalData(); } … public class Caller { … Data myData = new Factory().createData(); … Data Fact ory Call er moda mod main pkgmain
nal pkga Letztlich geht‘s immer um Typen-Sichtbarkeit: Exceptions Interne Exceptions können nach außen geworfen werden. Caller kann nur Oberklassen fangen. public class A { public void doIt() throws InternalException { ... } public class Caller { … try { new A().doIt(); } catch(Exception ex) {...} catch(RuntimeException rex) {…} … Call er moda Inter nal Excep tion Inter nalRun timeExc eption exports A mod main pkgmain
& Reads der module-info nicht reichen…? Neue Read-Beziehung vonnach Export/Open weiterer Packages Kommandozeile javac, java oder @file programmatisch --add-reads … java.lang. Module.addReads() --add-exports … --add-opens … java.lang. Module.addExports() Module.addOpens() Angabe im JAR-Manifest Add-Exports: … Add-Opens: … Vorsicht - Caller-sensitiv: Aufruf nur im eigenen Modul möglich!
nur öffentliche Schnittstelle von moda. Neues Modul braucht also keinen Zugriff auf interne Klassen. Blackbox-Test eines Moduls moda moda read exports pkga internal pkga $ java --module-path mlib\;amlib --add-modules modtest.blackbox -m junit/org.junit.runner.JUnitCore pkgblacktest.BlackBoxTest junit read modtest. blackbox pkg black test
für Whitebox-Tests eines Moduls moda Ein Whitebox-Test benötigt zum Test interne Klassen von moda aus dem Package pkgainternal. moda pkga internal pkga Unschön Ein Patch des JAR-Files moda.jar mit passender module-info.class ist i.d.R. keine Alternative. Funktioniert z.B. nicht bei Checksummen! exports
Test-Modul modtest.whitebox Wie erhält es Zugriff auf die internen Packages von moda? Whitebox-Test eines Moduls moda : Varianten 1a, b Statische Abhängigkeit zu Testcode Pflege der Skripte?! module moda { exports pkga; exports pkgainternal to modtest.whitebox; } a) Mit exports to der zu testenden Packages an modtest.whitebox $ javac --add-exports moda/pkgainternal=modtest.whitebox $ java --add-exports moda/pkgainternal=modtest.whitebox b) Dynamischer Export der zu testenden Packages mit --add-exports
Modul moda enthält auch die Testklassen. Aber wo verwaltet man diese? Whitebox-Test eines Moduls moda : Varianten 2a, b Testcode wird mit paketiert und deployed a) Testklassen sind Teil von moda. Testklassen können damit alle zu testenden Klassen aus moda sehen. b) Testklassen werden getrennt abgelegt. Zu Compile-Zeit und zur Test-Laufzeit werden sie dem Modul moda hinzugefügt („Patchen“).
System-Module-Path Observable Modules: „Was da ist“ java. base Module-Path mlib modmain Alle Module auf dem Module-Path zusammen mit den System-Modulen bilden das „Universum“ der Observable Modules.
ist die transitive Hülle aller Abhängigkeiten aller Root-Module der Observable Modules. Root-Module ist hier modmain Observable Modules System-Module-Path Configuration: „Was wirklich geladen wird“ Module-Path mlib modmain java. base modmain java. base $ java --module-path mlib -m modmain/pkgmain.Main
System-Module-Path Configuration: Weitere Module dazunehmen Module-Path mlib modmain java. base modmain java. base modx Weitere Root-Module werden Configuration mitgegeben über --add-modules modx $ java --module-path mlib --add-modules modx -m modmain/pkgmain.Main
System-Module-Path Configuration: Alle Module aus Module-Path dazunehmen Module-Path mlib modmain java. base modmain java. base modx Shortcut für „alle Module aus MP“ dazunehmen über ALL-MODULE-PATH $ java --module-path mlib --add-modules ALL-MODULE-PATH -m modmain/pkgmain.Main
Modul moda mehrfach auf dem Module-Path vorhanden, so wird nach Reihenfolge der Angabe eingezogen, hier im Beispiel aus mlib1 Keine Warning bei Inhalten bzw. Versionen! Observable Modules System-Module-Path Configuration: Vorsicht beim „Shadowing“ von Modulen Module-Path mlib1 modmain modmain Module-Path mlib2 moda java. base $ java --module-path mlib1;mlib2 -m modmain/pkgmain.Main moda moda
dem MP Modul in einem JAR Modul in einer JMOD-Datei Aus einer module- info.class Wie kann man Informationen zu einem Modul ausgeben? $ jar --file mlib/moda.jar –-describe-module $ jdeps --module-path mlib mlib/moda.jar $ jmod describe $JAVA_HOME/jmods/java.base.jmod $ javap -verbose module-info.class $ java --module-path mlib --describe-module moda
in der module-info! Stattdessen kann eine Modul-Version beim Paketieren des JAR-Files mitgegeben werden! Wie setzt man die Modul-Version? $ jar --file ./mlib/moda.jar –-describe-module [email protected] jar:file:///…/mlib/moda.jar/!module-info.class exports pkga1 requires java.base mandated requires modb requires modc transitive qualified exports pkga2 to modmain opens pkga3 contains pkgainternal $ jar --create --module-version=47.11alpha3 --file=./mlib/moda.jar –C mods/moda
Configuration Debugging Debugger gibt Modul aus Stacktrace gibt Modul mit aus Wie erhalte ich Informationen zur Laufzeit? $ java –Xdiag:resolver ... $ java –Xlog:module=debug|trace ... $ java --module-path ./mlib --list-modules ... über Class.getModule() pkgb.MyException: MyException's message at modb/pkgb.B.doItThrowException(B.java:13) at modmain/pkgmain.Main.main(Main.java:18) $ java --module-path ./mlib --show-module-resolution
4.7.1a Oxygen.1 von Oktober 2017 wird Java 9 unterstützt (alte Eclipse-Versionen mit Beta-Plugin besser meiden!) • Eclipse startet mit Java 9 • Java 9 als JRE nutzbar • Code-Completion für module-info für requires, exports, opens … • Launch und Debug kann Module-Path Noch buggy oder fehlt: Fehler bei Automatic Modules, JUnit-Dialoge ohne MP, Unnamed-Package-Compilefehler, keine Optionen für J9-Compiler einstellbar (z.B. --add-exports) Entwicklungstools: Eclipse
unverändert test-compile unterstützt Blackbox- und Whitebox-Tests. test noch mit Classpath. Abhängigkeiten müssen redundant in der pom und in der module-info modelliert werden. Build-Tools: Maven mit Java-9-Support … <dependency> <groupId>de.accso.jigsaw</groupId> <artifactId>moda</artifactId> <version>0.0.1-SNAPSHOT</version> </dependency> module modmain { requires moda; }
baut Blackbox- und Whitebox-Tests wie erwartet. Blackbox: Nur wenn eine module-info.java in src/test/java liegt, erzeugt Maven getrennte Module für Testcode und zu testendes Modul. Sonst automatisch Whitebox: Maven patcht die Testklassen in das Modul wie in unserer Variante 2b. Das surefire-plugin führt die Tests jedoch (noch) auf dem Classpath aus. Maven für Blackbox- und Whitebox-Tests $ javac --patch-module moda=patches/moda ...
module- info.java descriptors for given artifacts (Maven dependencies or local JAR files) Adding module descriptors to your project's JAR as well as existing JAR files (dependencies) Creating module runtime images https://github.com/moditect/moditect
ModuleDescriptor.Exports ModuleDescriptor.Opens ModuleDescriptor.Provides ModuleReference ModuleFinder Configuration Zugriff auf das Modulsystem über neue API Modulbeschreibung mit Name, Version, … ... mit allen Requires ... mit allen Exports … mit allen Opens … mit allen Provides aber Uses sind leider nur Strings Laufzeit-Referenz auf ein Modul Ein/alle Module finden („was da ist”) „Was geladen wurde“ java.lang.module.…
„DepVis“ zur Visualisierung von Modul-Graphen Ideen: requires-n-transitive, Filter auf einzelne Beziehungen, Packages, Hashes, nur Module der Configuration, mehr Konfiguration mit Farben & Co … https://github.com/accso/java9-jigsaw-depvis Basiert auf GraphViz http://www.graphviz.org/ mit Java-API https://github.com/kohsuke/graphviz-api Visualisierung und Textausgabe von Modulen auf Module-Path und im System mit Wildcard – Black-&Whitelisting Explicit, Automatic, Open requires (auch 1-transitive, static, mandated), exports-to, opens-to Concealed Packages uses und provides
Module darf keine Klassen im Unnamed Package enthalten. Resources sind dagegen im Unnamed Package weiterhin erlaubt. Klassen im Unnamed Package nicht mehr erlaubt src\moda\MyClassInTheUnnamedPackage.java:2: error: unnamed package is not allowed in named modules public class MyClassInTheUnnamedPackage { ^ 1 error Compile- Fehler
Laufzeit- Fehler beim Start Ein „Split“ eines Package auf mehrere Module ist nicht erlaubt! Gilt auch, wenn das Package nicht exportiert ist!! Selbst dann, wenn es keine Klassen-Duplikate in den beiden Modulen gibt!!! Split Package: Module müssen disjunkte Packages haben. Ausnahme: Gilt nicht für The Unnamed Module. src\modmainfoo\module-info.java:1: error: module modmainfoo reads package pkgfoo from both modsplitfoo1 and modsplitfoo2 module modmainfoo { ^ 1 error Error occurred during initialization of boot layer java.lang.LayerInstantiationException: Package pkgbar in both module modsplitbar1 and module modsplitbar2 Gilt nur für Module in einer gemeinsamen Configuration (nur auf Module-Path OK). Wie erkennt man Split-Package? https://github.com/accso/splitpackage-sniffer
die Verwendung von JDK-internen Klassen: Seit Java 8: Neue offizielle APIs ersetzen unsupportete APIs. Beispiel: sun.misc.BASE64Encoder java.util.Base64.Encoder Andere APIs werden schrittweise ersetzt, später nicht mehr zugänglich sein. Details siehe JEP 260: http://openjdk.java.net/jeps/260 JDK-interne APIs sind geschützt, nicht mehr zugreifbar! $ jdeps --jdk-internals ./classes pkgmain.Main -> jdk.internal.misc.SharedSecrets JDK internal API (java.base) Warning: JDK internal APIs are unsupported and private to JDK implementation that are subject to be removed or changed incompatibly and could break your application. Please modify your code to eliminate dependence on any JDK internal APIs. For the most recent update on JDK internal API replacements, please check: https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool
einen illegalen Zugriff: permit entspricht einem opens auf alle JDK-internen Packages, aber nur auf die Packages, die es bereits in Java 8 gab! Nur in Java 9 ist permit der Default – nur bis Release 10 (aka 18.3)! Der große Kill-Switch --illegal-access $ java --add-opens=java.base/sun.io=ALL-UNNAMED ... $ java --illegal-access=permit|warn|deny ... Einige prominente Frameworks sind noch nicht auf Java 9 umgestellt. Hauptproblem: Verwendung JDK-interner Klassen per Reflection. Lösung: --add-opens öffnet benötigte Packages für Classpath. • Nachteil: --add-opens muss in allen run-Skripten gesetzt werden! • Bricht zahlreichen existierenden Code!
ich diese Java8-Packages? Eine Text-Datei im JDK enthält die Konfiguration aller 1317 Packages von Java 8. Siehe java.base/jdk.internal.module.jdk8_packages.dat Auch online im Sourcen-Repository einsehbar unter http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/65464a307408/src/java.base/ share/classes/jdk/internal/module/jdk8_packages.dat
alle 6 Monate. Wechsel zu „time-based release train“ Nächstes Release bereits im März 2018 als JDK 10 (aka „18.3“) http://openjdk.java.net/projects/jdk/10/ Releases im März & September mit fertigen neuen Features Dazu vier weitere Releases im Jahr mit Security- und Bugfixes Alle 3 Jahre Releases mit LTS (Long-Term-Support), ab 9/2018 https://mreinhold.org/blog/forward-faster #javatrain http://mail.openjdk.java.net/pipermail/discuss/2017- September/thread.html#4281 Warum umsteigen? Neue Release-Policy nach Java 9!
„echtes“ Modul: Explicit Module enthält module-info in einem Modular JAR liegt auf dem Module-Path oder auf dem System- Module-Path Open Module ist Spezialfall eines Explicit Modules moda java. base modmain
in ein Modul umwandeln: Automatic Module Module-Path moda java. base JAR auf dem Module-Path modmain junit hat „reads“ auf alle anderen Module „exports“ + „opens“ aller Packages Ein Explicit Module muss ein Automatic Module requiren. Automatischer Name: - . junit-4.12.jar junit Named Modules := Explicit Modules + Automatic Modules
auf dem Classpath im „Unnamed Module“ Module-Path modmain moda The Unnamed Module java. base „exports“ aller Packages readable von Automatic Modules nicht ohne weiteres von Explicit Modules hat „reads“ auf alle Module junit a.jar hibernate .jar
Module-Path überdeckt den Classpath! Module-Path moda modmain java. base junit 1 The Unnamed Module a.jar Suchreihenfolge Module-Path The Unnamed Module Vorsicht bei gleichzeitiger Verwendung von Module-Path und Classpath! 2 hibernate .jar 1 2 pkga. A pkga. A Klasse pkga.A wird in moda gefunden! Keine Fehler- meldung, kein Split Package!
Anwendung (fast) unverändert mit Java 9 benutzen Java-System-Module sind auf dem System-Module-Path Module-Path The Unnamed Module java. base java.xml. bind main.jar a.jar b.jar commons- lang.jar Die Anwendung liegt auf dem Classpath (im Unnamed Module).
Anwendung (fast) unverändert mit Java 9 benutzen Module-Path The Unnamed Module java. base main.jar a.jar b.jar commons- lang.jar Hoffentlich keine oder nur minimale Anpassungen notwendig: • Compile- und Runtime-Option --add-modules java.xml.bind java.xml. bind
Anwendung (fast) unverändert mit Java 9 benutzen Module-Path The Unnamed Module java. base main.jar a.jar b.jar commons- lang.jar Vorsicht: Einige inkompatible JDK-Änderungen! Ggf. Updates nötig! Böse Falle: Manche externen Bibliotheken kommen nicht mit dem neuen Java-Versionsnummernkonzept zurecht (z.B. ASM)! Hoffentlich muss man nicht nur deswegen gleich auf die neueste Bibliotheksversion wechseln?! java.xml. bind
„Normales“ JAR in ein Explicit Module migrieren b.jar hängt von nichts ab. b.jar kann daher einfach in ein Explicit Module migriert werden. Compile- und Runtime-Option --add-modules modb notwendig The Unnamed Module main.jar a.jar commons- lang.jar Module-Path java. base b.jar modb java.xml. bind
JAR in ein Automatic Module migrieren a.jar hängt von commons-lang.jar ab. Wird daher erst in ein Automatic Module migriert, damit commons-lang.jar readable bleibt. Evtl. Package-Überschneidungen auflösen (Split-Package)! Module-Path java. base modb The Unnamed Module main.jar commons- lang.jar a.jar moda java.xml. bind
Third-Party-Lib in Automatic Module migrieren commons.lang wird in ein Automatic Module migriert. Um commons.lang in ein Explicit Module zu migrieren, müsste module- info erstellt werden (… das überlassen wir besser dem Maintainer) Module-Path java. base modb moda commons .lang The Unnamed Module main.jar commons- lang.jar java.xml. bind
Automatic Module in Explicit Module migrieren moda kann nun in ein Explicit Module migriert werden, weil commons.lang nun ebenfalls im Module-Path liegt. Module-Path java. base modb commons .lang The Unnamed Module main.jar moda moda java.xml. bind
Den Rest migrieren Module-Path java. base java. sql c junit b main Module-Path java. base modb commons .lang moda main mod main The Unnamed Module main.jar java.xml. bind
werden Module in sogenannte Layer gruppiert: Jede Modul-“Instanz“ liegt in einem Layer. Layer • haben leider keinen Namen, toString()-Ausgabe zeigt alle Module • haben jeweils eine eigene Configuration. • benötigen mindestens je einen Classloader (pro Layer / pro Module). Es gibt mindestens einen Layer zur Laufzeit („Boot Layer“). Layer bilden eine Hierarchie (aber kein Baum, da mehrere Parents möglich!) Eine Jigsaw-Anwendung besteht zur Laufzeit aus Layern
2 – Module aufgeteilt auf Layer-Hierarchie Pseudo- Parent Empty Layer Foo-Layer Bar-Layer #1 Bar-Layer #2 Boot- Layer Layerübergreifende Aufrufe von „oben nach unten“ und umgekehrt via Reflection Kein Split-Package mit mehreren (Geschwister-) Layern Statische Aufrufe möglich von modfoo und modbar nach modcommon Module in verschiedenen Versionen möglich
public != accessible Selbst bei Reflection. Abhängigkeitsmodell wirkt sehr statisch. • Für die Java-Plattform passt das, da hat man alle Klassen zur Compile-Zeit. Anwendungen sind viel dynamischer. • Requires: Warum fehlen Scopes wie „Test“ und „Runtime“ (vgl. Maven)? Zugriffsschutz ist sehr restriktiv. • Opt-in oder Opt-out? • Exports: Keine Unterstützung von Package-Wildcards! • Erster Accessibility-Level ist nun das „Package“. (Warum eigentlich?) Gleiche Konzepte nicht immer konsistent benamt (requires reads) Kritik …
Ein Modul hat keine (echten) Versionen - nur informell Kein Alias für ein Modul möglich außer --patch-module Module sind nicht gruppierbar. Keine Hierarchie (vgl. Maven parent.pom) Gut: Aggregator-Module über requires transitive Redundanzen zwischen Tools und module-infos module-info wird zu .class-File kompiliert. Ist aber doch gar keine Klasse. Warum nicht MANIFEST.MF? Oder wenigstens Human-Readable-Format? Warum kann man bei --add… keine module-info übergeben / patchen?
Schritt zur echter Komponentenorientierung! Jigsaw und Java 9 sind (schon lange) stabil. Allerdings sehr viel Dynamik: Implementierungen (und auch Konzepte, gerade zu Reflection) wurden bis zuletzt geändert. Kill-Switch war Antwort auf die JCP-Ablehnung im April 2017. Migration ist gut machbar, aber wird mühsam! • Modul-Kategorien: „Wo kommt was her?“ ist nicht trivial! • MP & CP: Bekommen wir das jemals richtig aussortiert? • Observable != Configuration ClassNotFoundException • Letzte Rettung: --add-modules ALL-MODULE-PATH … und Lob!
mrtnlhmnn
seike460
kno3a87
nekomatu
marokanatani
zsmb
ivargrimstad
tsucchinoko
petamoriken
fukubaka0825
10tera
yusukebe
0si43
chrisshort
jeffersonlam
moore
nonsquared
jcasabona
tammyeverts
kneath
iamctodd
keithpitt
marcelosomers
bryan
keavy
