in Geduldsspiel! Das Einsteiger-Puzzle für Entwickler. Das neue Modulsystem Jigsaw in Java 9
Martin Lehmann, Rüdiger Grammes, Kristine Schaal: „Ein Geduldsspiel! Das Einsteiger-Puzzle für Entwickler. Das neue Modulsystem Jigsaw in Java 9“.
Vortrag bei der Java User Group Frankfurt, 21. Dezember 2016
MODULSYSTEM JIGSAW IN JAVA 9 21. DEZEMBER 2016 | DR. RÜDIGER GRAMMES, MARTIN LEHMANN, DR. KRISTINE SCHAAL | JUGF EIN GEDULDSSPIEL! DAS EINSTEIGER-PUZZLE FÜR ENTWICKLER
Modularisierung und Jigsaw Reliable Configuration Ablösung des Classpath (fehleranfällig, wenn Klassen mehrfach enthalten sind – Reihenfolge). Neu: explizite Definition von Abhängigkeiten. Strong Encapsulation Eine Komponente kann ihr öffentliches API definieren und verhindern, dass auf Implementierungsgeheimnisse zugegriffen wird. Scalable Java SE Platform Die Java-Plattform selber wird modularisiert. Damit kann man individuell angepasste und „schlanke“ Plattformen bauen.
Menge von Java-Packages & Resources. Wird in ein „Modular JAR“ kompiliert. Dieses liegt im neuen Module-Path. Modul-Namen müssen eindeutig sein (. und _ sind im Namen erlaubt, - nicht) • „read“-Abhängigkeitsbeziehungen zu einem oder mehreren anderen Modulen • „exports“: Welche Packages des Moduls werden exportiert? (Default: nichts!) moda Ein Modul wird ein „First-Class-Citizen“ in Java modb read exports pkg a pkg b pkgb inter nal
Java 9: Readability und Accessibility read moda pkg a Check zu Compile-Zeit und zur Laufzeit von 1. neu: Readability „ich benötige dieses Module, 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 modb
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 Modules liegt in Datei module-info.java im obersten Module-Sourcenverzeichnis. 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
https://github.com/accso/java9-jigsaw-examples/ Java mit Jigsaw Build b144 (jdk1.9.0_ea-b144-x64_20161111_build5709) Eclipse 4.7 Oxygen (M4) plus Java9-Support (BETA) • Konvention: 1 Eclipse-Projekt == 1 Module • Module-Namen: mod*, Package-Namen: pkg* (interne *internal) • Module-Abhängigkeiten über Projekt-Abhängigkeiten in Eclipse nachmodelliert • Launch-Files starten die JAR-Files im Module-Path • Jedes Beispiel in einem eigenen Workspace *) Compile- und Run-Skripte für die Bash (auch für Windows, z.B. mit Babun) Unsere Beispiele *) Ein Workspace kann nicht 2 Projekte gleichen Namens enthalten.
immer um Typen-Sichtbarkeit. Auch bei Ableitung. Funktioniert: • Oberklasse Data ist sichtbar nach außen, weil Package pkga exportiert. • Ihre Methoden sind von außerhalb aufrufbar. • Unterklasse InternalData ist nicht sichtbar nach außen. • Ihre Methoden sind von außerhalb nicht aufrufbar. exports pkga inter nal pkga Data moda Inte rnal Data
nal pkga moda Fact ory Inte rnal Data Data exports Funktioniert: Factory gibt Instanzen der Unterklasse InternalData zurück. Instanzen behalten natürlich ihren Typ. Es werden Methoden der Unterklasse aufgerufen, z.B. InternalData.toString() public class Factory { public Data createData() { return new Data(); } public Data createInternalData1() { return new InternalData(); } … Letztlich geht‘s immer um Typen-Sichtbarkeit. Auch bei Ableitung.
bei Ableitung Was passiert, wenn eine Methodensignatur eine nicht exportierte Klasse zurückgibt pkga inter nal pkga moda Fact ory public class Factory { public Data createData() { return new Data(); } public Data createInternalData1() { return new InternalData(); } // return type wird nicht exportiert! public InternalData createInternalData2() { return new InternalData(); } } Factory kompiliert. Code in anderem Module kompiliert nicht bei Aufruf: Inte rnal Data Data exports Factory.createInternalData2() Letztlich geht‘s immer um Typen-Sichtbarkeit. Auch bei Ableitung.
immer um Typen-Sichtbarkeit. Gilt auch bei Interfaces. exports pkga inter nal pkga IDat a moda Inte rnal Data Funktioniert: Factory gibt Instanzen der Unterklasse InternalData zurück. Instanzen behalten natürlich ihren Typ. Es werden Methoden der Implementierung aufgerufen. public class Factory { public IData createData() { return new InternalData(); } // return type wird nicht exportiert! public InternalData createInternalData2() { return new InternalData(); } … Fact ory
(deren Package nicht exportiert ist) MyInternalException MyInternalRuntimeException können nach außerhalb des Modules geworfen werden. Typ bleibt auch hier erhalten. Alles funktioniert „ganz normal“, nur eben kein catch auf den internen Exception-Typ. catch auf Oberklassen wie Exception, RuntimeException problemlos möglich. Letztlich geht‘s immer um Typen-Sichtbarkeit. Gilt auch bei Exception-Handling.
mit Reflection? … und mit Serialisierung, Dependency- Injection, Bytecode-Enhancement, ...? Zur Erinnerung 1. Check: Readable, über requires? 2. Check: Accessible, über exports? 3. Check von public,protected,<package>,private Gilt alles auch bei Reflection! Convenience bei Reflection: read-Beziehung ist immer vorhanden. Aber Accessibility-Checks greifen auch „scharf“ bei Reflection: Klassen von nicht exportierten Packages sind nicht zugreifbar. • Gilt für newInstance, getField, getMethod • Gilt auch für setAccessible(true)
Zugriff nur zur Laufzeit, nicht zur Compile-Zeit opens öffnet für „Deep Reflection“ mit setAccessible(true) Spezialfall „open module“: alle Packages des Moduls sind „open“ opens öffnet ein Package zur Laufzeit Zugriff … 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
Laufzeit- Fehler beim Start Ein „Split“ von Packages auf mehrere Module ist nicht erlaubt! Gilt auch, wenn das Package nicht exportiert ist. Selbst dann, wenn es keine Klassen-Duplikate in den beiden Modules gibt. Split Package: Modules 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 VM java.lang.reflect.LayerInstantiationException: Package pkgbar in both module modsplitbar1 and module modsplitbar2 at java.lang.reflect.Layer.fail(java.base@9-ea/Layer.java:449) at java.lang.reflect.Layer.checkBootModulesForDuplicatePkgs(java.base@9-ea/Layer.j at java.lang.reflect.Layer.defineModules(java.base@9-ea/Layer.java:357) at jdk.internal.module.ModuleBootstrap.boot(java.base@9-ea/ModuleBootstrap.java:29 at java.lang.System.initPhase2(java.base@9-ea/System.java:1925) Gilt nur für Module in einer gemeinsamen Configuration – nur auf Module-Path OK.
Module-interne Resources möglich mit Funktioniert weiterhin: Resource-Encapsulation wird durchgesetzt (funktionierte lange nicht). Ein Module sollte auf Resources eines anderen Modules nicht zugreifen dürfen, scheint aber noch nicht zu funktionieren?! Resource-Schutz und -Handling in Modules this.class.getModule().getResourceAsStream("myapp.properties") this.getClass().getResource ("myapp.properties") ClassLoader.getPlatformClassLoader().getResource("myapp.properties") that.class.getModule().getResourceAsStream("that.properties")
System-Module-Path Observable Modules: „Was da ist“ java. base Module-Path modmain Alle Module auf dem Module-Path, sowie die System-Module bilden das „Universum“ der Observable Modules.
ist die transitive Hülle aller „reads“-Abhängigkeiten aller Root-Module der Observable Modules. Default-Root-Module hier: modmain Observable Modules System-Module-Path Configuration: „Was wirklich geladen wird“ Module-Path modmain java. base java --module-path mlib -m modmain/pkgmain.Main modmain java. base
kann man einer Configuration als Root-Module mit --add-modules hinzufügen: Observable Modules System-Module-Path Configuration: „Was wirklich geladen wird“ plus „addMods“ Module-Path modmain java. base modmain java. base java --module-path mlib --add-modules mlib/modx.jar -m modmain/pkgmain.Main modx modx
Modules modfib : 4 Varianten Ein Whitebox-Test benötigt zum Test interne Klassen von modfib. Das Package pkgfib.internal ist aber nicht exportiert. modfib exports pkgfib internal pkgfib
Module modtest.whitebox Wie erhält es Zugriff auf die nicht-exportierten Klassen von modfib? Whitebox-Test eines Modules modfib : Varianten 1a, b Statische Abhängigkeit zu Testcode Etwas besser. Aber: Pflege der Skripte?! module modfib { exports pkgfib; exports pkgfibinternal to modtest.whitebox; } a) Mit „exports to“ der zu testenden Packages an modtest.whitebox javac --add-exports modfib/pkgfib.internal=modtest.whitebox java --add-exports modfib/pkgfib.internal=modtest.whitebox b) Dynamischer Export der zu testenden Packages mit --add-exports
enthält auch die Testklassen. Aber wo verwaltet man diese? Whitebox-Test eines Modules modfib : Varianten 2a, 2b Testcode wird ebenfalls paketiert und deployed a) Testklassen direkt bei modfib ablegen. Testklassen können so alle zu testenden Klassen aus modfib sehen. b) Testklassen getrennt ablegen. Zu Compile-Zeit und zur Test-Laufzeit dem Module modfib hinzufügen („Patchen“)
„echtes“ Module: Explicit Module Explicit Module in einem JAR liegt auf dem Module-Path enthält module-info Open Module ist Spezialfall eines Explicit Modules modb java. base modmain
in ein Module umwandeln: Automatic Module Module-Path modb java. base Automatic Module JAR auf den Module-Path legen modmain junit Automatisch: „reads“ auf alle Module, „exports“ aller Packages (incl. „opens“) Ein Explicit Module muss ein Automatic Module requiren. Automatischer Name: - . junit-4.12.jar junit Named Modules := Explicit Modules + Automatic Modules
Classpath: The Unnamed Module The Unnamed Module Alle JARs auf dem Classpath sind ein einziges Module Module-Path modmain modb The Unnamed Module java. base Exports aller Packages Readable durch alle(!) Automatic Modules, aber nicht durch Explicit Modules „reads“ auf alle Modules junit b.jar hibernate .jar
und The Unnamed Module interagieren Module-Path modb modmain java. base junit 1 The Unnamed Module b.jar Suchreihenfolge Module-Path The Unnamed Module Vorsicht bei gleichzeitiger Verwendung von Module-Path und The Unnamed Module! 2 hibernate .jar 1 2 pkgb. B pkgb. B Klasse pkgb.B wird in modb gefunden! Keine Fehler- meldung wie bei Split Package!
Module-Informationen aus JAR, aus module-info.class Oder Auslesen der Module-Informationen aus JMOD-Datei Auslesen der Module-Informationen einer module-info.class - Datei Module-Informationen auslesen jar --file mlib/modmain.jar --print-module-descriptor jdeps --module-path mlib mlib/modmain.jar jmod describe java.base.jmod javap -verbose module-info.class
zur Visualisierung eines Modul-Graphen Ideen: req-transitive (n-transitiv), Filter auf einzelne Beziehungen, Uses/Provides, Packages, Hashes, Open, 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 DepVis kann visualisieren: … Module im Module-Path … Module im System … mit Black- & Whitelisting … Explicit Modules und Automatic Modules … requires, requires-transitive (1-transitiv), requires-mandated, exports-to
plus Java9-Plugin (BETA): • Eclipse startet mit Java 9 • module-info: Das meiste wird erkannt, auch Sichtbarkeiten. Code-Completion für requires-Module, exports-Packages • Es fehlt: Launch-Einstellungen für Module-Path, Automatic Modules, .... Maven, Gradle, Netbeans, … bieten Unterstützung für Java 9 Mühsame Pflege wird hoffentlich durch IDEs und Build-Tools erledigt: • requires-Pflege Maven-POM Eclipse-.classpath • exports -Pflege Package-Konventionen wie „…internal“ (?) • Alle Kommandozeilenoptionen für javac und java Wie steht‘s um Tools?
noch nicht final, Diskussionen u.a. noch zu … Exporte nur zur Laufzeit, v.a. für Reflection (dynamic->Weak->Open)? Module-Abhängigkeiten nur zur Compile-Zeit („requires static“)? Laufzeit-Beziehungen lazy auflösen? Annotations für Module Deprecation für Module > 1 Module in 1 JAR (so wie Fat-JARs), dazu Multi-Release-JARs? ... Teilweise sehr fundamentale Kritik auf den Mailinglisten.
public != accessible Erster Accessibility-Level ist nun das „Package“. (Warum eigentlich?) Abhängigkeitsmodell ist sehr statisch über Namen. Kein Alias für ein Module möglich (außer --patch-module) Warum keine Scopes wie „Test“ und „Runtime“ (vgl. Maven)? Zugriffsschutz ist sehr restriktiv. Opt-in oder Opt-out? Leider keine Unterstützung von Exports-Package-Wildcards! Ein Module hat keine (echten) Versionen - nur informell module-info wird zu .class-File kompiliert. Ist aber doch gar keine Klasse. Warum nicht MANIFEST.MF? Oder wenigstens Human-Readable-Format? Modules sind nicht gruppierbar. Keine Hierarchie möglich (vgl. parent.pom) Kritik …
requires transitive Der richtige Schritt zur echter Komponentenorientierung! Jigsaw und Java 9 sind sehr stabil. Allerdings ändern sich immer noch Implementierungen (und auch Konzepte, gerade zu Reflection) Migration ist gut machbar, aber wird mühsam! • Module-Kategorien: „wo kommt was her?“ ist nicht trivial! • MP & CP: Bekommen wir das jemals richtig aussortiert? … und Lob!
mrtnlhmnn
chriskrycho
naoya
free_world21
seyfoyun
soutaro
forrep
hokaccha
ssssota
ckazu
toshi0383
makotoshimazu
akarin
eileencodes
mraible
deanohume
jnunemaker
chriscoyier
sstephenson
lynnandtonic
lara
iamctodd
carmenintech
jakevdp
jeffersonlam
