Komponentendesign und Modularity-Patterns mit dem Java-Modulsystem Jigsaw

Vortrag Martin Lehmann, Kristine Schaal: "Komponentendesign und Modularity-Patterns mit dem Java-Modulsystem Jigsaw".
Herbstcampus 2018, 05. September 2018
https://www.herbstcampus.de/veranstaltung-7061-komponentendesign-und-modularity-patterns-mit-dem-java-modulsystem-jigsaw.html?id=7061

Komponentenbasierte Software ist eigentlich nichts Neues. Mit dem Jigsaw-Modulsystem steht seit Java 9 nach über 20 Jahren Java-Entwicklung nun ein natives Sprachmittel zur Verfügung, um Komponenten zu definieren und in der Architektur zu verankern. Was bisher nur mit Tools wie Maven bzw. mit statischer Code-Analyse möglich war, ist nun direkt verfügbar.

Wir beleuchten mögliche Komponentendesigns und betrachten verschiedene bekannte Modularity-Design-Patterns von Kirk Knoernschild http://www.kirkk.com/modularity/

Wir zeigen, ob und wie man diese Patterns mit Jigsaw umsetzen kann.
Wie kann man diese Patterns mit Jigsaw umsetzen, welche Patterns werden unterstützt, welche erfordern zusätzliche Klimmzüge, was geht nicht? Insbesondere betrachten wir Patterns zu Komponentendesign, Abhängigkeiten, Schnittstellen und Test.

Transcript

1. Copyright © Accso – Accelerated Solutions GmbH 1 v.3 1 v.3.12 MARTIN LEHMANN, DR. KRISTINE SCHAAL Herbstcampus 2018, 5. September 2018 @mrtnlhmnn @krschaal Modularity-Patterns mit Java 9 / Jigsaw
2. Copyright © Accso – Accelerated Solutions GmbH 3 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 Software- entwickler und -architekt in der Softwareentwicklung in diversen Projekten der Individual- entwicklung für Kunden verschiedener Branchen. Seit den Zeiten von Java 1.0 beschäftigt er sich mit Java als Programmiersprache und als Ökosystem. martin.lehmann@accso.de @mrtnlhmnn www.xing.com/profile/Martin_Lehmann3 Kristine Schaal, Accso - Accelerated Solutions GmbH Softwarearchitektin Dr. Kristine Schaal ist als Softwarearchitektin bei der Accso - Accelerated Solutions GmbH tätig. Sie arbeitet seit 20 Jahren in der Softwareentwicklung und ist in Projekten der Individual- entwicklung für Kunden verschiedener Branchen unterwegs, technisch überwiegend im Java- Umfeld. kristine.schaal@accso.de @krschaal www.xing.com/profile/Kristine_Schaal
3. Copyright © Accso – Accelerated Solutions GmbH 4 Project Jigsaw seit 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  Reihenfolgeprobleme). Scalable Java SE Platform Die Java-Plattform ist nun modularisiert. Man kann individuell angepasste, „schlanke“ Plattformen bauen. JSR 376 für das „Java Platform Module System“ (JPMS) Project Jigsaw seit Java 9-Release vom 21. September 2017 enthalten. Aktuell: Releases 9.0.4 und 10.0.2 (und bald 11) JEP 261, 200, 201, 220, 260, 282 mit Modulsystem, modularisiertem JDK und der Kapselung interner APIs
4. Copyright © Accso – Accelerated Solutions GmbH 6 Modularity Patterns Der Pattern- Katalog
5. Copyright © Accso – Accelerated Solutions GmbH 7 Kirk Knoernschild Java Application Architecture Modularity Patterns with Examples Using OSGi Series: Robert C. Martin Series Paperback: 384 pages Publisher: Prentice Hall; 1 edition March 25, 2012 ISBN-10: 0321247132 ISBN-13: 978-0321247131 http://www.kirkk.com/modularity/ https://mreinhold.org/blog/jigsaw-complete
6. Copyright © Accso – Accelerated Solutions GmbH 8 Base Patterns Manage Relationships Design module relationships Module Reuse Emphasize reusability at the module level Cohesive Modules Module behavior should serve a singular purpose Dependency Patterns Acyclic Relationships Module relationships must be acyclic Levelize Modules Module relationships should be levelized Physical Layers Module relationships should not violate the conceptual layers Container Independence Modules should be independent of the runtime container Independent Deployment Modules should be independently deployable units Usability Patterns Published Interface Make a module’s published interface well known External Configuration Modules should be externally configurable Default Implementation Provide modules with a default implementation Module Facade Facade as a coarse-grained entry point to … fine-grained underlying implementation Extensibility Patterns Abstract Modules Depend upon the abstract elements of a module Implementation Factory Use factories to create a module’s implementation classes Separate Abstractions Place abstractions and the classes that implement them in separate modules Utility Patterns Collocate Exceptions Exceptions should be close to the classes that throw them Levelized Build Execute the build in accordance with module levelization Test Module Each module should have a … test module that validates it’s behavior and illustrates it’s usage Pattern Catalog http://www.kirkk.com/ modularity/pattern-catalog/
7. Copyright © Accso – Accelerated Solutions GmbH 9 Base Pattern Manage Relationships Design module relationships
8. Copyright © Accso – Accelerated Solutions GmbH 10 Base Pattern Manage Relationships Pattern Komponenten = wieder- verwendbare „Software- Bausteine“ Wohldefinierte Schnittstellen Eingehende Schnittstellen Ausgehende Schnittstellen Der Grad der Abhängigkeiten bestimmt die Komplexität einer Anwendung maßgeblich. Vorteile Komponenten brechen den Monolithen auf. Nachvollziehbare Aus- wirkungen von Änderungen Es wird nur geladen, was wirklich benötigt wird. Es wird nur geladen, was wirklich modelliert wurde. Nachteile
9. Copyright © Accso – Accelerated Solutions GmbH 11 Module := Menge von Java-Packages & Resources Wird in ein „Modular JAR“ kompiliert. Dieses liegt im neuen Module-Path. Module-Namen müssen eindeutig sein (erlaubt sind . und _ , aber nicht -) Im Module-Deskriptor stehen: • Name • Abhängigkeiten • Zugriffsschutz Keine weiteren Syntax- oder Sprachkonstrukte! Ein Module als „First-Class-Citizen“ in Java module moda { requires modb; exports pkg1; opens pkg2; } moda/module-info.java
10. Copyright © Accso – Accelerated Solutions GmbH 12 Module := Menge von Java-Packages & Resources • „read“-Abhängigkeits- beziehungen zu anderen Modulen • „exports“: Welche Packages des Modules werden exportiert? (Default: nichts!) moda Ein Module als „First-Class-Citizen“ in Java modb read exports pkga pkgb inter nal pkg b
11. Copyright © Accso – Accelerated Solutions GmbH 14 Base Pattern Manage Relationships … mit Jigsaw Komponente als Module Beziehungen Keine Scopes (wie in Maven) Statische Bindung über Namen Dynamische Bindung zur Startzeit Nutzung Statische Aufrufe Dynamisch per Reflection Pattern Komponenten = wieder- verwendbare „Software- Bausteine“ Wohldefinierte Schnittstellen Eingehende Schnittstellen Ausgehende Schnittstellen Der Grad der Abhängigkeiten bestimmt die Komplexität einer Anwendung maßgeblich.
12. Copyright © Accso – Accelerated Solutions GmbH 15 Ein Module kann ein anderes Module nur benutzen, wenn es eine „read“-Beziehung zu ihm hat (aka: „requires“). Manage Relationships Explizite Abhängigkeiten modb module moda { // read auf modb requires modb; } read modc Das Module moda hat eine read-Beziehung zu Module modb, jedoch keine zu modc  moda kann nur auf modb zugreifen. moda
13. Copyright © Accso – Accelerated Solutions GmbH 16 Abhängigkeiten können als Laufzeit-„optional“ deklariert werden. Manage Relationships Optionale Abhängigkeiten modb module moda { // optionale // Abhängigkeit requires static modb; } read ? moda modb muss zur Compilezeit vorhanden sein. modb ist optional zu Link/Runtime.
14. Copyright © Accso – Accelerated Solutions GmbH 17 moda muss in seinem Code auf solche optionalen Abhängigkeiten reagieren, entsprechend fehleranfällig ist das Konstrukt. Manage Relationships Optionale Abhängigkeiten modb read ? moda private static Optional<MyBFactory> createMyBFactoryIfPresent() { try { return Optional.of(new MyBFactory()); } catch (NoClassDefFoundError err) { return Optional.empty(); } }
15. Copyright © Accso – Accelerated Solutions GmbH 18 Base Pattern Manage Relationships Optionale Abhängigkeiten? Transitive Abhängigkeiten? Versionierung? Gruppierungen? Hierarchien? Remote oder lokal? Checks zu Compile-Time? Checks zu Start/Runtime? Vertiefte Konzepte … mit Jigsaw Ja! Ja! Nein (nur informell)! Nicht einfach*! Nicht einfach*! Nur lokal, keine Verteilung! Ja! Ja! *) Zumindest nicht wie in Maven mit group-id. Nicht-triviale Lösungen über Aggregrator-Modules und ModuleLayer.
16. Copyright © Accso – Accelerated Solutions GmbH 19 Jigsaw-Module-Graphen z.B. mit DepVis https://github.com/accso/ java9-jigsaw-depvis Basiert auf GraphViz http://www.graphviz.org/ mit Java-API https://github.com/kohsuke/graphviz-api
17. Copyright © Accso – Accelerated Solutions GmbH 20 Dependency Pattern Acyclic Relationships Module relationships must be acyclic
18. Copyright © Accso – Accelerated Solutions GmbH 21
19. Copyright © Accso – Accelerated Solutions GmbH 25 Usability Pattern Published Interface Make a module’s published interface well known
20. Copyright © Accso – Accelerated Solutions GmbH 26 Usability Pattern Published Interface Pattern Komponente definiert ihre öffentliche Schnittstelle. Nutzer verwenden die Komponente nur über diese Schnittstelle. Von außen ist kein Zugriff auf die Implementierung möglich.
21. Copyright © Accso – Accelerated Solutions GmbH 27 Usability Pattern Published Interface Pattern Komponente definiert ihre öffentliche Schnittstelle. Nutzer verwenden die Komponente nur über diese Schnittstelle. Von außen ist kein Zugriff auf die Implementierung möglich. Vorteile Fördert explizite Definition von Komponenten-Grenzen Dokumentation Änderung der gekapselten Implementierung hat keine Auswirkung auf Nutzer.
22. Copyright © Accso – Accelerated Solutions GmbH 28 Usability Pattern Published Interface Pattern Komponente definiert ihre öffentliche Schnittstelle. Nutzer verwenden die Komponente nur über diese Schnittstelle. Von außen ist kein Zugriff auf die Implementierung möglich. Nachteile Höhere Komplexität durch Indirektion zum Erzeugen der Implementierung Instabile Schnittstellen Abwärtskompatibilitätsfalle Law of Leaky Abstraction: „All non-trivial abstractions, to some degree, are leaky.” (Joel Spolsky)
23. Copyright © Accso – Accelerated Solutions GmbH 29 Usability Pattern Published Interface Pattern Komponente definiert ihre öffentliche Schnittstelle. Nutzer verwenden die Komponente nur über diese Schnittstelle. Von außen ist kein Zugriff auf die Implementierung möglich. Abgrenzungen Manche Komponenten haben keine echte Schnittstelle, z.B. Datentypen-Komponenten. Reflektiver Zugriff durch Frameworks auch auf gekapselte Implementierung sinnvoll Vollständige Implementierung austauschen?  Pattern „Separate Abstractions“
24. Copyright © Accso – Accelerated Solutions GmbH 32 public interface MyInterface { public MyData myMethod (String param) throws MyException; } Interfaces Factories zum Erzeugen der Implementierung Datentypen Exceptions Was gehört zur Schnittstelle einer Komponente?
25. Copyright © Accso – Accelerated Solutions GmbH 33 Published Interface exports von Packages module modb { exports pkg.myapi; } read moda pkg. myimpl modb exports pkg. myapi Nur exportierte Packages eines Modules sind von außen zugreifbar. Per Default nichts exportiert. Export nur auf Package-Ebene möglich! Keine Wildcards möglich! Gerichteter Export an ein / mehrere Module mit exports to <module>
26. Copyright © Accso – Accelerated Solutions GmbH 34 Published Interface exports von Packages module modb { exports pkg.myapi; } read moda pkg. myimpl modb exports pkg. myapi Checks zu Compile-Zeit und zur Laufzeit: 1. neu: Readability (read) 2. neu: Accessibility (exports) 3. Sichtbarkeitsmodifier public, private, protected, <pkg> Gilt alles auch für System-Module (wie java.base)
27. Copyright © Accso – Accelerated Solutions GmbH 35 Published Interface exports von Packages module modb { exports pkg.myapi; } read moda pkg. myimpl modb exports Varianten zur Umsetzung des Patterns: API- und Implementierungsklassen in verschiedene Packages legen Oder Implementierung zur API dazulegen – als „package-sichtbar“. pkg. myapi
28. Copyright © Accso – Accelerated Solutions GmbH 37 exports für statische Zugriffe – opens für Laufzeit-Zugriffe 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 Reflection auf z.B. public-Methode Reflection auf z.B. private-Methode. setAccessible(true) Published Interface Reflektive Laufzeit-Zugriffe
29. Copyright © Accso – Accelerated Solutions GmbH 38 Usability Pattern Separate Abstractions Place abstractions and the classes that implement them in separate modules
30. Copyright © Accso – Accelerated Solutions GmbH 39 Usability Pattern Separate Abstractions Pattern Trenne Implementierung von API  in verschiedene Komponenten API-Komponente hat keine Abhängigkeit zu der Implementierung. Auswahl/Konfiguration einer Implementierung erfolgt außerhalb API-Komponente. Factories nicht enthalten. Vorteile Implementierung kann komplett ausgetauscht werden, erlaubt späte Wahl (zur Laufzeit). Beispiel: Datenbank-Treiber Weitere Indirektionen Mehr Aufwand Höhere Komplexität, Zusammenspiel schwerer nachvollziehbar Nachteile
31. Copyright © Accso – Accelerated Solutions GmbH 40 Usability Pattern Separate Abstractions - 3 Ebenen pkg.service IService1 IService2
32. Copyright © Accso – Accelerated Solutions GmbH 41 Usability Pattern Separate Abstractions - 3 Ebenen pkg.service IService1 IService2 pkg.foobar IFoo IBar
33. Copyright © Accso – Accelerated Solutions GmbH 42 Usability Pattern Separate Abstractions - 3 Ebenen pkg.service IService1 IService2 pkg.foobar IFoo IBar api
34. Copyright © Accso – Accelerated Solutions GmbH 43 Usability Pattern Separate Abstractions - 3 Ebenen pkg.service.blue Impl1 Impl2 pkg.foobar.blue FooImpl BarImpl blue.impl
35. Copyright © Accso – Accelerated Solutions GmbH 44 Usability Pattern Separate Abstractions - 3 Ebenen pkg.service.green OtherImpl 1 OtherImpl 2 pkg.foobar.green FooImpl BarImpl green.impl
36. Copyright © Accso – Accelerated Solutions GmbH 45 Usability Pattern Separate Abstractions - 3 Ebenen pkg.service.red RedImpl1 RedImpl2 red.impl
37. Copyright © Accso – Accelerated Solutions GmbH 46 Usability Pattern Separate Abstractions - 3 Ebenen client factory
38. Copyright © Accso – Accelerated Solutions GmbH 47 Usability Pattern Separate Abstractions - 3 Ebenen client Auswahl der Implementierung als „ganze“ Komponente factory
39. Copyright © Accso – Accelerated Solutions GmbH 48 Usability Pattern Separate Abstractions - 3 Ebenen client Auswahl der Implementierung in „Teilen“ (einmalig oder nach Bedarf) factory
40. Copyright © Accso – Accelerated Solutions GmbH 49 Separate Abstractions mit Jigsaw-Modules green.impl red.impl blue.impl api read read exports read
41. Copyright © Accso – Accelerated Solutions GmbH 50 Separate Abstractions 1. „Factory-Module“ green.impl red.impl blue.impl api factory client
42. Copyright © Accso – Accelerated Solutions GmbH 51 green.impl red.impl blue.impl api factory client Separate Abstractions 1. „Factory-Module“ read read read
43. Copyright © Accso – Accelerated Solutions GmbH 52 green.impl red.impl blue.impl api factory client Separate Abstractions 1. „Factory-Module“ exports to exports to exports to Factory muss Implementierungsklassen kennen!
44. Copyright © Accso – Accelerated Solutions GmbH 53 green.impl red.impl blue.impl api DI- Framework client Zugriff per Reflection mit „opens“ – z.B. für Spring-Fwk Separate Abstractions 2. „DI-Module“ opens to opens to opens to
45. Copyright © Accso – Accelerated Solutions GmbH 55 Schnittstelle java.sql.Driver Implementierung in Module java.sql im MySQL-Driver Dynamische Bindung beim Start über ServiceLoader, also keine statische Auflösung über Module-Namen wie bei requires! module com.mysql.jdbc { requires java.sql; … // Implementiert Schnittstelle provides java.sql.Driver with com.mysql.jdbc.Driver; } Separate Abstractions 3. Dynamische Bindung module java.sql { … // Definiert und exportiert // Schnittstelle uses java.sql.Driver; exports java.sql; }
46. Copyright © Accso – Accelerated Solutions GmbH 57 Usability Pattern Module Facade Facade as a coarse-grained entry point to another module’s underlying implementation
47. Copyright © Accso – Accelerated Solutions GmbH 58 Usability Pattern Module Facade Facade as a coarse-grained entry point to another module’s underlying implementations
48. Copyright © Accso – Accelerated Solutions GmbH 59 Usability Pattern Module Facade Pattern Vgl. GOF-Patterns „Facade“, „Adapter“, „Decorator“, „Mediator“ Eine Komponente dient als zentrale Facade zu anderen Komponenten. Abhängigkeit idealerweise nur zur Facade nötig, nicht zu den „dahinter“ liegenden Komponenten Vorteile Kapselt dahinterliegende Details an zentraler Stelle Kapselt Schnittstellen Höhere Lesbarkeit Einfachere Nutzung Erzwingt Reihenfolgen erlaubt automatische Vor- / Nach-Bearbeitung
49. Copyright © Accso – Accelerated Solutions GmbH 60 Module Facade mit eigenen Facade-Modules In selbstgeschriebenen „Facade-Modules“ kann man andere Module kapseln. module modfacade { requires modx; requires mody; }
50. Copyright © Accso – Accelerated Solutions GmbH 61 Module Facade Transitive Abhängigkeiten module modfacade { requires modx; requires transitive mody; } Jigsaw ermöglicht es, Abhängigkeiten transitiv weiterzugeben. Klassen aus mody werden via modfacade an modapp durchgereicht.
51. Copyright © Accso – Accelerated Solutions GmbH 62 1-transitiv 2-transitiv Module Facade Transitive Abhängigkeiten
52. Copyright © Accso – Accelerated Solutions GmbH 63 Usability Pattern Module Facade … mit Jigsaw requires transitive in module-info reicht Abhängigkeit automatisch weiter Ermöglicht nicht die Kapselung „dahinter“ liegender APIs Im Gegenteil werden diese ja durchgereicht! Pattern Vgl. GOF-Patterns „Facade“, „Adapter“, „Decorator“, „Mediator“ Eine Komponente dient als zentrale Facade zu anderen Komponenten. Abhängigkeit idealerweise nur zur Facade nötig, nicht zu den „dahinter“ liegenden Komponenten
53. Copyright © Accso – Accelerated Solutions GmbH 64 Usability Pattern Module Facade Proxy … mit Jigsaw requires transitive in module-info reicht Abhängigkeit automatisch weiter Ermöglicht nicht die Kapselung „dahinter“ liegender APIs Im Gegenteil werden diese ja durchgereicht! Mehr ein Proxy als eine Facade. Pattern Vgl. GOF-Patterns „Facade“, „Adapter“, „Decorator“, „Mediator“ Eine Komponente dient als zentrale Facade zu anderen Komponenten. Abhängigkeit idealerweise nur zur Facade nötig, nicht zu den „dahinter“ liegenden Komponenten
54. Copyright © Accso – Accelerated Solutions GmbH 65 Module Proxy Aggregator-Module Transitive Abhängigkeiten erlauben, leere Aggregator-Module zu definieren. Diese dienen ausschließlich dazu, Abhängigkeiten zu einer Menge anderer Modulen an zentraler Stelle zu verwalten. modapp
55. Copyright © Accso – Accelerated Solutions GmbH 66 Module Proxy Aggregator-Module Transitive Abhängigkeiten erlauben, leere Aggregator-Module zu definieren. Diese dienen ausschließlich dazu, Abhängigkeiten zu einer Menge anderer Modulen an zentraler Stelle zu verwalten. mod. aggrega tor modapp
56. Copyright © Accso – Accelerated Solutions GmbH 67 Utility Pattern Test Module Each module should have a corresponding test module that validates it’s behavior …
57. Copyright © Accso – Accelerated Solutions GmbH 68 Utility Pattern Test Module Pattern Zu jeder Komponente eine korrespondierende Testkomponente erstellen. Blackbox-Test testet nur die öffentlichen Schnittstelle. Die Testkomponente hängt nicht von weiteren Komponenten ab (Mocking). Separate Integrationstest- komponenten erstellen Vorteile Komponenten sind unabhängig voneinander testbar, Fehler leichter lokalisierbar Dokumentation der Nutzung der Schnittstelle Hoher Aufwand durch Mocks Nachteile
58. Copyright © Accso – Accelerated Solutions GmbH 69 read pkg black test moda. test. black Blackbox-Tests werden in separates Jigsaw-Module ausgelagert. Dieses Testmodule benötigt keinen Zugriff auf interne Klassen. Test Module Blackbox-Tests pkga internal exports moda pkga
59. Copyright © Accso – Accelerated Solutions GmbH 70 pkga internal pkga internal …Test exports moda pkga Test Module Whitebox-Tests Whitebox-Test testet interne Klassen von moda aus pkgainternal. Verschiedene Varianten denkbar, z.B. Test-Module & „exports to“ Besser: Testcode getrennt ablegen und für Compile der Tests und für Testdurchführung in das Module „reinpatchen“.
60. Copyright © Accso – Accelerated Solutions GmbH 72 Es gibt leider keinen einfachen Weg, dass ein Module als Alias für ein anderes Modul operiert (nicht möglich über die Module-Namen). Mögliche Abhilfe: Verwaltung von Modulen auf verschiedenen Module-Paths (z.B. getrennt für Produktion und für Test). • Module-Path (MP): Verzeichnis, auf dem die Modular JARs abgelegt sind (ähnlich Classpath) • Anders als beim Classpath ist nicht jedes Module auf dem MP automatisch verfügbar. Stattdessen muss es explizit zur Laufzeit geladen werden. Test Module Mocks für Tests
61. Copyright © Accso – Accelerated Solutions GmbH 73 EXKURS zu Module-Path Was ist da? Was wird geladen?
62. Copyright © Accso – Accelerated Solutions GmbH 74 Observable Modules 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.
63. Copyright © Accso – Accelerated Solutions GmbH 75 Die Configuration ist die transitive Hülle aller Abhängigkeiten ausgehend von allen Root-Module. 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
64. Copyright © Accso – Accelerated Solutions GmbH 78 Ist ein Modul moda mehrfach auf dem Module-Path vorhanden, so wird nach Reihenfolge der Angabe geladen, hier im Beispiel aus mlib2 Keine Warnung! 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 mlib2;mlib1 -m modmain/pkgmain.Main moda moda
65. Copyright © Accso – Accelerated Solutions GmbH 79 ENDE EXKURS zu Module-Path Was ist da? Was wird geladen?
66. Copyright © Accso – Accelerated Solutions GmbH 80 Es gibt leider keinen einfachen Weg, dass ein Module als Alias für ein anderes Modul operiert (nicht möglich über die Module-Namen). Mögliche Abhilfe: Verwaltung von Modulen auf verschiedenen Module-Paths (z.B. getrennt für Produktion und für Test). • Module-Path (MP): Verzeichnis, auf dem die Modular JARs abgelegt sind (ähnlich Classpath) • Anders als beim Classpath ist nicht jedes Module auf dem MP automatisch verfügbar. Stattdessen muss es explizit zur Laufzeit geladen werden. Test Module Mocks für Tests
67. Copyright © Accso – Accelerated Solutions GmbH 81 Test Module Mocks für Tests Dieses Shadowing kann man für Test-Mocks gezielt ausnutzen: • Lege Mock-Module (mit dem gleichen Namen wie der Mockee) in einen separaten „Module-Path für Test“. • Setze die Reihenfolge der MPs so, dass die Test-Mocks „vorne stehen“. Observable Modules System-Module-Path Module-Path mlib.production modmain modmain Module-Path mlib.test moda java. base moda moda
68. Copyright © Accso – Accelerated Solutions GmbH 82 Dependency Patterns Levelize Modules Module relationships should be levelized Physical Layers Module relationships should not violate the conceptual layers Levelized Build Execute the build in accordance with module levelization
69. Copyright © Accso – Accelerated Solutions GmbH 83 Ein Anwendungssystem ist modular aufgebaut Säule 2 Säule 3 … Säule 1 Schicht Anwendungskern Schicht Persistenz Component Component Component Component Component Component Component Component Component Component Component Component Anwendung
70. Copyright © Accso – Accelerated Solutions GmbH 84 Anwendung Schicht Präsentation Schicht Anwendungskern Schicht Persistenz Technische Schichten und fachliche Säulen Säule 2 Säule 3 … Säule 1 Component Component Component Component Component Component Component Component Component Component Component Component
71. Copyright © Accso – Accelerated Solutions GmbH 88 Jigsaw-Modules als gerichteter Graph … mit Jigsaw Jigsaw erstellt einen Abhängigkeitsgraph: Modellierung der Abhängig- keiten mit requires Keine zyklischen Abhängigkeiten Dieser Graph sollte auch die Schichten und Säulen abbilden. Eine Unterstützung durch Jigsaw gibt es dafür nicht.
72. Copyright © Accso – Accelerated Solutions GmbH 89 Wie schneidet ich Module? Design und Architektur!
73. Copyright © Accso – Accelerated Solutions GmbH 90 Wie schneide (designe) ich Module? Modul-Schnitt Wie groß ist so ein Module? Wo sind (sinnvolle) Module- Grenzen? Treiber sind Kohäsion und Koppelung
74. Copyright © Accso – Accelerated Solutions GmbH 91 Wie schneide (designe) ich Module? Kohäsion Hohe Kohäsion („Bindung“) innerhalb einer Komponente Das Zusammenspiel der Bestandteile (Klassen etc.) in einer Komponente ist sehr stark ausgeprägt. Koppelung Lose Koppelung zwischen Komponenten über wenige, „dünne“ Schnittstellen Änderungen einer Komponente sollen sich möglichst lokal auswirken, sollen andere Komponenten nicht beeinflussen
75. Copyright © Accso – Accelerated Solutions GmbH 92 John Ousterhout A Philosophy of Software Design Paperback: 190 pages Publisher: Yaknyam Press 1 edition (April 6, 2018) Language: English ISBN-10: 1732102201 ISBN-13: 978-1732102200 https://www.youtube.com/watch?v=bmSAYlu0NcY
76. Copyright © Accso – Accelerated Solutions GmbH 93 Wie schneide (designe) ich Module? Shallow Modules Deep Modules Funktionalität Interface Funktionalität mehr Abstraktion Interface
77. Copyright © Accso – Accelerated Solutions GmbH 94 Laubsägenmassaker Lob & Kritik
78. Copyright © Accso – Accelerated Solutions GmbH 95 Lob Der richtige Schritt zur echter Komponentenorientierung! Gute Basis für die meisten Modularity Patterns. Gut nutzbar für Greenfield-Projekte.
79. Copyright © Accso – Accelerated Solutions GmbH 96 Drastische Semantikänderung: public != accessible Erster Accessibility-Level ist das „Package“. (Warum eigentlich?) Zugriffsschutz ist sehr restriktiv. Opt-in oder Opt-out? Keine Wildcards! module-info als Java-Datei? Abhängigkeitsmodell ist statisch Alias-Modules schwierig Keine Versionen, Scopes, Gruppierung Kritik
80. Copyright © Accso – Accelerated Solutions GmbH 97 Probleme aller Art lauern überall – im schlimmsten Fall als Laufzeitfehler. APIs (im JDK) nicht mehr zugreifbar Update der gesamten Umgebung (IDE, Bibliotheken, Build-Tools bis zu Produktion) Mischen von MP und Classpath Observable vs. Configuration Module-Kategorien wie Automatic, Unnamed, Explicit Split-Package-Problem Neuer Java-Versionsstring Vorsicht: Aufwändige Migration!
81. Copyright © Accso – Accelerated Solutions GmbH 100 Als PDF-Download bei http://accso.de/java/ JavaSPEKTRUM- Sonderdruck heise/iX Sonderheft „Java 2017“ Accso – Accelerated Solutions GmbH T | +49 6151 13029-0 E | info@accso.de @ | www.accso.de Berliner Allee 58 | 64295 Darmstadt Moltkestraße 131a | 50674 Köln Balanstraße 55 | 81541 München
82. Copyright © Accso – Accelerated Solutions GmbH 101 https://twitter.com/ThePracticalDev/status/ 763470048463912960
83. Copyright © Accso – Accelerated Solutions GmbH 107 107 107 Accso – Accelerated Solutions GmbH T | +49 6151 13029-0 E | info@accso.de @ | www.accso.de Berliner Allee 58 | 64295 Darmstadt Moltkestraße 131a | 50674 Köln Balanstraße 55 | 81541 München https://speakerdeck.com/mrtnlhmnn @accso @mrtnlhmnn @krschaal https://github.com/accso/java9-jigsaw-examples/ https://github.com/accso/java9-jigsaw-depvis/ http://accso.de/java/