Ein Geduldsspiel! Das 1000-Module-Puzzle für Entwickler. Das neue Modulsystem Jigsaw in Java 9
Martin Lehmann, Kristine Schaal: „Ein Geduldsspiel! Das 1000-Module-Puzzle für Entwickler. Das neue Modulsystem Jigsaw in Java 9“. Herbstcampus 2016, Nürnberg
MODULSYSTEM JIGSAW IN JAVA 9 31. AUGUST 2016 | MARTIN LEHMANN, DR. KRISTINE SCHAAL | HERBSTCAMPUS 2016, NÜRNBERG EIN GEDULDSSPIEL! DAS 1000-MODULE- PUZZLE FÜR ENTWICKLER
von? Änderung Bemerkung 31.08.2016 Martin Lehmann, Kristine Schaal finale Version für Herbstcampus 2016 01.09.2016 Martin Lehmann Minimalkorrekturen bei den neuen --add... Optionen (die –Xadd… ersetzten): Diese werden ohne : geschrieben, stattdessen Blank nach der Option. Optionen für javac und java ändern sich, werden GNU-Style, siehe JEP293
9 kommt 2017 das lange angekündigte Modulsystem Jigsaw - eine grundlegende Strukturänderung von Java-Plattform und - Sprache -, mit deren Auswirkungen man sich möglichst früh beschäftigen sollte. Wir erläutern technische Grundlagen, zeigen anhand von Code-Beispielen, wie das Modulsystem aussieht und welche Designentscheidungen getroffen wurden. Wir zeigen Motive und Ziele für die Einführung eines Modulsystems. Weiterhin gehen wir auf Auswirkungen von Modulen zur Compile- und Laufzeit ein, z.B. auf häufig in Frameworks anzutreffende generische Ansätze wie Reflection oder Callbacks. Abschließend behandeln wir fortgeschrittene Themen wie Migrationspfade, Architektur und Komponentenschnitt. Skills Java-Grundlagen (Sprache und Architektur), idealerweise Verständnis von Maven oder Ivy Lernziele Zuhörer erhalten eine Einführung in das neue Jigsaw-Modulsystem, verstehen die Grundlagen und die Auswirkungen auf Architektur und Komponentenschnitt. Außerdem lernen sie Migrationspfade nach Java 9 kennen. 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. 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. Abstract http://www.herbstcampus.de/veranstaltung-5217-das-neue-modulsystem-jigsaw-in-java-9.html?id=5217
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.
Dependencies, Resolution, Encapsulation, Non-Interference: In allen Phasen (Compile, Laufzeit). Exports müssen von außen überschreibbar sein. Resource Encapsulation Services: Binding, Selective Binding Java Platform Modularization Interoperabilität mit anderen Modulsystemen (OSGi explizit genannt) Refactoring: Module aufspaltbar / zusammenlegbar, ohne Auswirkungen auf Clients Whitebox-Tests Schrittweise Migration, Weiterbenutzung von existierenden Tools wie Maven Linking („optimierte Plattform bauen“) Keine Verschlechterung der Performance Non-Requirements: Versionierung – nur als Versionsstring in Module ?! Die wichtigsten Requirements aus der Spec-Dokumentation
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 Readability: „ich benötige dieses Module, will darauf zugreifen“ Accessibility: „auf was genau dürfen andere zugreifen?“ (unabhg. von Classloadern!) 1. Check: Readable (über requires)? Accessible (über exports)? 2. Check wie bisher der Sichtbarkeitsmodifier public,protected,<package>,private de.my. package. ximpl de.my. package. internal de.my. package exports de.my.mod
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 9-ea+127-jigsaw-nightly-h5308-20160721 Eclipse 4.6 Neon 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.
mit Reflection? … und mit Serialisierung, Dependency- Injection, Bytecode-Enhancement, ...? Zur Erinnerung 1. Check: Readable (über requires)? Accessible (über exports)? 2. Check wie bisher 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) „exports dynamic“ erlaubt Zugriff nur zur Laufzeit, nicht zur Compile-Zeit
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
umgekehrt: • Oberklasse ist nicht sichtbar nach außen • Unterklasse ist sichtbar nach außen pkga Data moda exports pkga inter nal Inte rnal Data Letztlich geht‘s immer um Typen-Sichtbarkeit. Auch bei Ableitung.
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.
(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.
eines Interfaces muss nicht exportiert sein, um benutzt werden zu können. Beispiel Callback-Interface: exports pkg sst ICall back Call ee pkg inter nal Call back Impl read Letztlich geht‘s immer um Typen-Sichtbarkeit. Gilt auch bei Implementierung eines Interfaces.
java.sql.Driver Implementierung in Module java.sql in JDBC-Driver keine feste Bindung über Module-Namen wie bei Requires Interfaces und Implementierung mit Uses/Provides in der module-info 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; }
Module-interne Resources möglich mit Funktioniert weiterhin: Leider keine Resource-Encapsulation. (Ursprüngliches Requirement dazu wird wohl gekippt.) Ein Module kann auf Resources eines anderen Modules zugreifen, sofern dieses readable ist. Resource-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")
Laufzeit- Fehler beim Start Kein „Split“ eines Packages auf zwei Modules 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.
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“)
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
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 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!
Anwendung unverändert mit Java 9 benutzen Die Java-Plattform-Module auf dem System-Module-Path Module-Path The Unnamed Module java. base java. sql main.jar b.jar c.jar hibernate.jar Die Anwendung liegt auf dem Classpath (im Unnamed Module). Keine Anpassungen notwendig, jedoch ohne Named Modules. ABER: Wenige inkompatible Änderungen in Java 9, z.B. kein Boot-Classpath
„Unabhängiges“ JAR in Named Module migrieren c.jar hängt von nichts ab. c kann einfach in ein Named Module migriert werden. Compile- und Runtime-Option --add-modules notwendig! The Unnamed Module main.jar b.jar hibernate.jar Module-Path java. base java. sql c.jar c
JAR in Automatic Module migrieren b.jar hängt von hibernate.jar ab. Wird als Automatic Module migriert, damit hibernate.jar readable ist. Ein JAR kann nur (unverändert) migriert werden, wenn es keine Package- Überschneidungen mit anderen Modulen gibt (sonst Split-Package)! Module-Path java. base java. sql b c The Unnamed Module main.jar hibernate.jar b.jar
Third-Party-Lib in Automatic Module migrieren hibernate wird in ein Automatic Module migriert. Um hibernate auch noch in ein Explicit Module zu migrieren, müsste eine module-info erstellt werden. Machbar, aber: Aufwändig, benötigt Sourcen & Build, erstellt Fork plus Abhängigkeiten Module-Path java. base java. sql c b hiber nate The Unnamed Module main.jar hibernate.jar
Automatic Module in Explicit Module migrieren b kann nun in ein Explicit Module migriert werden, weil hibernate nun ebenfalls im Module-Path liegt. Module-Path java. base java. sql c b hiber nate b The Unnamed Module main.jar
Den Rest migrieren Module-Path java. base java. sql c junit b main Module-Path java. base java. sql c hiber nate b main main The Unnamed Module main.jar
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
ModuleDescriptor ModuleDescriptor.Requires ModuleDescriptor.Exports ModuleReference Configuration Module Layer Zugriff auf das Modulsystem über neue APIs Ein/alle Module finden („Observable Modules”) Modulbeschreibung mit Name, Version, … ... mit allen Requires ... mit allen Exports Laufzeit-Referenz auf ein Modul „Was geladen wird“ java.lang.module.… java.lang.reflect.… Reflection-Support
zur Visualisierung eines Modul-Graphen Ideen: req-public (n-transitiv), Filter auf einzelne Beziehungen, Uses/Provides, 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 DepVis kann visualisieren: … Modules im Module-Path … Modules im System … mit Black- & Whitelisting … Explicit Modules und Automatic Modules … requires, requires-public (1-transitiv), requires-mandated, exports-to
plus Java9-Plugin (BETA): • Eclipse startet mit Java 9 • module-info: Das meiste wird erkannt (aber z.B. kein „exports dynamic“). Sichtbarkeiten werden erkannt. Code-Completion für requires-Module, exports-Packages • Es fehlt: Launch-Einstellungen für Module-Path, Automatic Modules, .... 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 Maven, Gradle, Netbeans bieten erste Unterstützung für Java 9 (siehe Quality Outreach Programm des OpenJDK) Wie steht‘s um Tools?
viele weitere Themen in Java 9 (zu wenig Zeit ;-) Module und JavaDoc Module und Annotations Modifier von Requires , Exports Mandated, Synthetic, Public, … ClassLoader hat sich im Grundprinzip nicht geändert Layer Kapselung von Modulen zur Laufzeit -Xbootclasspath fällt weg Upgradeable Modules i.W. der Ersatz für Extension-Mechanismus Nutzung von jlink für Linking von optimierten Runtime-Images JEP238 für Multi-Release-JAR-Files JAR-File mit Java-Release-spezifischen Versionen JMOD-Format und -Dateien i.W. JARs mit Native-Code usw. Neuer Versionsstring in Java9 u.a. fällt Präfix „1.“ endlich weg Instrumentierung geht nicht mehr für sehr früh geladenen Code sun.misc.Unsafe nun in jdk.internal.misc.Unsafe
go! Roadmap bis Java 9 Early Draft Review 9/2016 Public Review 11/2016 Proposed Final Draft 1/2017 Final Release 3/2017 Roadmap bis Java 9 http://openjdk.java.net/projects/jdk9/ 2016/05/26 Feature Complete 2016/08/11 All Tests Run 2016/09/01 Rampdown Start 2016/10/20 Zero Bug Bounce 2016/12/01 Rampdown Phase2 2017/01/26 Final Rel.Candidate 2017/03/23 General Availability Roadmap für den JSR 376 (aus der Mailingliste)
noch nicht fertig (?), Diskussionen u.a. noch zu … Exporte nur zur Laufzeit, v.a. für Reflection („exports dynamic“)? 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 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 …
und Lob Ein Module hat keine (echten) Versionen - nur informell Kein Alias für ein Module möglich außer --patch-module Modules sind nicht gruppierbar. Keine Hierarchie (vgl. Maven parent.pom) Gut: Aggregator-Module über requires-public 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 sehr stabil. Mit Eclipse kann man bereits jetzt halbwegs arbeiten. Migration ist machbar, aber wird mühsam! • Module-Kategorien: „wo kommt was her?“ ist nicht trivial! • MP & CP: Bekommen wir das jemals richtig aussortiert? • Observable != Configuration ClassNotFoundException Nimm-Alles-Schalter --add-modules ALL-MODULE-PATH … und Lob!
mrtnlhmnn
arthur1
rmakiyama
tamai_63
taiki45
roguelynn
pyama86
daniloab
hollycummins
genetec
andpad
chriskrycho
findyinc
lauravandoore
stephaniewalter
chriscoyier
jrom
rasmusluckow
erikaheidi
cherdarchuk
colly
tammielis
pedronauck
maggiecrowley
