Workshop - Ein Geduldsspiel! Das 1000-Module-Puzzle für Entwickler. Das neue Modulsystem Jigsaw in Java 9
Martin Lehmann, Kristine Schaal, Rüdiger Grammes: „Ein Geduldsspiel! Das 1000-Module-Puzzle für Entwickler. Das neue Modulsystem Jigsaw in Java 9“.
Frankfurter Entwicklertag 2017, Tutorial-Day, 14. Februar 2017
MODULSYSTEM JIGSAW IN JAVA 9 17. FEBRUAR 2017 | DR. RÜDIGER GRAMMES, MARTIN LEHMANN, DR. KRISTINE SCHAAL | FRANKFURTER ENTWICKLERTAG EIN GEDULDSSPIEL! DAS 1000-MODULE- PUZZLE FÜR ENTWICKLER.
9 kommt das lange angekündigte Modulsystem Jigsaw. Jigsaw ist eine grundlegende Strukturänderung von Java-Plattform und - Sprache, mit deren Auswirkungen man sich möglichst früh beschäftigen sollte. Eine erste Jigsaw-Version im September 2015 hatte für so viele Diskussionen gesorgt, dass Java9-Roadmap und Feature-Freeze um ein halbes Jahr auf 2017 verschoben wurden. In diesem Tutorial erläutern wir Grundlagen von Jigsaw. Wir 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 bekannte Frameworks basieren? • Welche anderen Konstrukte gibt es (Beispiel: Services)? • Wie sehen Tools aus? IDE? Build/Dependency-Management? Abstract https://entwicklertag.de/frankfurt/2017/ein-geduldsspiel-das-1000-module-puzzle-f%C3%BCr-entwickler-das-neue-modulsystem-jigsaw-java-9 Frühere Java-Versionen waren immer abwärtskompatibel. Jigsaw ist eine tiefgreifende strukturelle Veränderung: • Wie geht man mit externen Bibliotheken um? • Welche Ansätze gibt es zu Migrationspfaden sowie zu Architektur und Design? 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 (mindestens) für Windows zur Verfügung (verteilen wir als ZIP-Paket auf USB-Stick) bzw. legen wir nach Github.
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 einem Modul! 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 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
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; }
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“)
Übung ist das Verstehen der Mechanismen zur Strukturierung von Tests. Die Güte der Testfälle und Testabdeckung ist heute mal nebensächlich! a) Blackboxtests in einem eigenen Modul zum Test der öffentlichen Schnittstelle zu testenden Fibonacci-Modul modfib b) Whiteboxtests zum Test des Implementierungs- geheimnis der Fibonacci-Zahlen Die Whiteboxtests werden zur Compile- und Laufzeit in modfib hineingepatcht. Aufgabe 2: Erstellen von Blackbox- und Whiteboxtests modfib/ module-info.java pkfib/ … pkgfib.internal/ … modtest.blackbox/ module-info.java pkgblacktest/ BlackBoxTest.java modtest.whitebox/ pkgfib/ WhiteBoxTest.java modfib/
2c: Optionen in @<file> auslagern --patch-module modfib=patches/modfib --module-path mlib\;amlib --add-reads modfib=junit --add-modules ALL-MODULE-PATH -m junit/org.junit.runner.JUnitCore pkgfib.WhiteBoxTest Inhalt der Datei run-whiteboxtest-options java @run-whiteboxtest-options Optionen in Datei auslagern (Beispiel: Skript zum Ausführen der Whiteboxtests) Optionen auf CLI und in Datei können gemischt werden (jedoch Reihen- folge beachten!)
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.
immer um Typen-Sichtbarkeit. Auch bei Interfaces. exports pkgfib. inter nal pkgfib Fibon acci modfib Fibon acci Impl Funktioniert: FibonacciFactory gibt Instanzen der Implementierung FibonacciImpl zurück. Instanzen behalten natürlich ihren Typ. public class FibonacciFactory { public Fibonacci createFibonacciCalculator() { return new FibonacciImpl(); } … Fib. 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.
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.
„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!
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
Übung ist, den Umgang mit den neuen und erweiterten Plattform- Tools für die Arbeit mit Modulen zu erlernen, sowie die neue Modul-API kennenzulernen. a) Nutzung der Plattform-Tools jmod und jdeps b) Nutzung der API von java.lang.module zur Ausgabe von Module- Informationen Aufgabe 3: jmod, jdeps und neue API
Laufzeit: Jedes Modul in einem Layer Layer • haben leider keinen Namen • haben jeweils eine eigene Configuration. • benötigen mindestens je einen Classloader (pro Layer / pro Module). Mindestens ein Layer zur Laufzeit Layer bilden eine Hierarchie (sind aber kein Baum – mehrere Parents möglich!) Eine Jigsaw-Anwendung besteht zur Laufzeit aus Layern
mit java.lang.reflect.Layer public Layer createLayer(Layer parent, String modulePath, List<String> modulesNames) { // get new Configuration from parent’s Configuration, // from ModuleFinder results and from the list of module names Configuration conf = parent.configuration() .resolveRequires(ModuleFinder.of(), ModuleFinder.of(Paths.get(modulePath)), modulesNames); // create and return new Layer, here with new Classloader for all // modules (which delegate to the System-Classloader) return parent.defineModulesWithOneLoader(conf, ClassLoader.getSystemClassLoader()); }
Variante 2 – Module aufgeteilt auf Layer-Hierarchie Pseudo- Parent empty-Layer Layerübergreifende Aufrufe von „oben nach unten“ und umgekehrt via Reflection Split-Package mit mehreren (Geschwister-) Layern? Kein Problem, solange nur getrennte CLs verwendet werden
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
https://github.com/accso/java9-jigsaw-examples/ Java mit Jigsaw Build b148 (9-ea+b148-x64_20161213_build5846) 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.
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 die Standard-Tools?
viele weitere Themen in Java 9 (zu wenig Zeit ;-) Module und JavaDoc Module und Annotations Modifier von Requires , Exports Mandated, Synthetic, Transitive, … 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
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/12/22 Feature Ext. Complete 2017/01/05 Rampdown Start 2017/02/09 All Tests Run 2017/02/16 Zero Bug Bounce 2017/03/16 Rampdown Phase 2 2017/07/06 Final Release Candidate 2017/07/27 General Availability Roadmap für den JSR 376 (aus der Mailingliste)
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
karupanerura
spbaya0141
genetec
roguelynn
forrep
youkidearitai
akki_megane
mkdev10
pictiny
mugi_uno
findyinc
sylph01
frogandcode
cromwellryan
chriscoyier
zakiwarfel
danielanewman
sstephenson
chrislema
rocio
reverentgeek
myddelton
andyhume
malarkey
