Modularity-Patterns mit Java 9 / JigsawProject Jigsaw seit Java 9-Release vom 21. September 2017 enthalten. Aktuell: Releases 9.0.4 und 10.0.1. JEP 261, 200, 201, 220, 260, 282 mit

Copyright © Accso – Accelerated Solutions GmbH 1v.3 1v.3.12

MARTIN LEHMANN, DR. KRISTINE SCHAAL

Java Forum Stuttgart, 5. Juli 2018

@mrtnlhmnn @krschaal

Modularity-Patternsmit Java 9 / Jigsaw

Copyright © Accso – Accelerated Solutions GmbH 2

Mit Java 9 kam im September 2017 (endlich!) das lange angekündigte und lang ersehnte 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.

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

Wir betrachten verschiedene bekannte Modularity-Design-Patterns und zeigen, wie man diese mit Jigsaw umsetzen kann, darunter Patterns zu Architektur- und Komponentenschnitt, Patterns zu Abhängigkeiten, Patterns zu Test, Patterns zu Erweiterbarkeit und zur Evolution / Migration.

Welche Patterns werden gut unterstützt, welche erfordern zusätzliche Klimmzüge oder gar eigene Erweiterungen? Welche Features kann Jigsaw in Java 9 noch nicht (Beispiel: Modul-Versionierung)?

Abstract – Java Forum Stuttgart 2018https://www.java-forum-stuttgart.de/de/Slot+3+2018.html#A3

https://www.java-forum-stuttgart.de/de/Slot+3+2018.html#A3


Martin Lehmann, Accso - Accelerated Solutions GmbHCheftechnologe

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.

[email protected] @mrtnlhmnn www.xing.com/profile/Martin_Lehmann3

Kristine Schaal, Accso - Accelerated Solutions GmbHSoftwarearchitektin

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.

[email protected] @krschaal www.xing.com/profile/Kristine_Schaal

mailto:[email protected]

http://www.xing.com/profile/Martin_Lehmann3

mailto:[email protected]

https://www.xing.com/profile/Kristine_Schaal


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.1.

JEP 261, 200, 201, 220, 260, 282 mit Modulsystem, modularisiertem JDK und der Kapselung interner APIs


Module mit 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 müssen möglich bleiben

Schrittweise Migration, Weiterbenutzung von existierenden Tools wie Maven

Linking, um optimierte Plattform bauen zu können

Keine Verschlechterung der Performance

Versionierung ist explizit ausgeklammert (Modul hat nur einen Versionsstring!)

Wichtige Anforderungen aus der JPMS-Spec


ModularityPatterns

Der Pattern-Katalog


Kirk KnoernschildJava Application Architecture Modularity Patterns with Examples Using OSGi

Series: Robert C. Martin SeriesPaperback: 384 pagesPublisher: Prentice Hall; 1 editionMarch 25, 2012ISBN-10: 0321247132ISBN-13: 978-0321247131

http://www.kirkk.com/modularity/https://mreinhold.org/blog/jigsaw-complete

http://www.kirkk.com/modularity/

https://mreinhold.org/blog/jigsaw-complete


Base PatternsManage Relationships Design module relationshipsModule Reuse Emphasize reusability at the module levelCohesive Modules Module behavior should serve a singular purpose

Dependency PatternsAcyclic Relationships Module relationships must be acyclicLevelize Modules Module relationships should be levelizedPhysical Layers Module relationships should not violate the conceptual layersContainer Independence Modules should be independent of the runtime containerIndependent Deployment Modules should be independently deployable units

Usability PatternsPublished Interface Make a module’s published interface well knownExternal Configuration Modules should be externally configurableDefault Implementation Provide modules with a default implementationModule Facade Facade as a coarse-grained entry point to … fine-grained underlying implementation

Extensibility PatternsAbstract Modules Depend upon the abstract elements of a moduleImplementation Factory Use factories to create a module’s implementation classesSeparate Abstractions Place abstractions and the classes that implement them in separate modules

Utility PatternsCollocate Exceptions Exceptions should be close to the classes that throw themLevelized Build Execute the build in accordance with module levelizationTest 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/

http://www.kirkk.com/modularity/2009/12/manage-relationships/

http://www.kirkk.com/modularity/2009/12/module-reuse/

http://www.kirkk.com/modularity/2009/12/cohesive-modules/

http://www.kirkk.com/modularity/2009/12/acyclic-relationships/

http://www.kirkk.com/modularity/2009/12/levelize-modules/

http://www.kirkk.com/modularity/2009/12/physical-layers/

http://www.kirkk.com/modularity/2009/12/container-independence/

http://www.kirkk.com/modularity/2009/12/independent-deployment/

http://www.kirkk.com/modularity/2009/12/published-interface/

http://www.kirkk.com/modularity/2009/12/external-configuration/

http://www.kirkk.com/modularity/2010/08/defaultimplementation/

http://www.kirkk.com/modularity/2009/12/module-facade/

http://www.kirkk.com/modularity/2009/12/abstract-modules/

http://www.kirkk.com/modularity/2009/12/implementation-factory/

http://www.kirkk.com/modularity/2009/12/separate-abstractions/

http://www.kirkk.com/modularity/2009/12/colocate-exceptions/

http://www.kirkk.com/modularity/2009/12/levelized-build/

http://www.kirkk.com/modularity/2009/12/test-module-2/

http://www.kirkk.com/modularity/pattern-catalog/


Base PatternManage Relationships

Design module relationships


Base Pattern Manage Relationships

PatternKomponenten = wieder-verwendbare „Software-Bausteine“

Wohldefinierte Schnittstellen

Eingehende Schnittstellen

Ausgehende Schnittstellen

Der Grad der Abhängigkeiten bestimmt die Komplexitäteiner Anwendung maßgeblich.

VorteileKomponenten 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


Module := Menge von Java-Packages & ResourcesWird 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


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

pkgapkgbinternal

pkgb



… mit Jigsaw

Module-Deskriptor

Module-Name

Abhängigkeiten

Zugriffsschutz

Keine weiteren Syntax- oder Sprachkonstrukte!








… mit JigsawKomponente als Module

Beziehungen

Keine Scopes (wie in Maven)

Statische Bindung über Namen

Dynamische Bindung zur Startzeit

Nutzung

Statische Aufrufe

Dynamisch per Reflection







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



Optionale Abhängigkeiten?

Transitive Abhängigkeiten?

Versionierung?

Gruppierungen?

Hierarchien?

Remote oder lokal?

Checks zu Compile-Time?

Checks zu Start/Runtime?

Vertiefte Konzepte … mit JigsawJa!

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.


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

https://github.com/accso/java9-jigsaw-depvis

http://www.graphviz.org/

https://github.com/kohsuke/graphviz-api


Dependency PatternAcyclic Relationships

Module relationships must be acyclic



Dependency Pattern Acyclic Relationships

Patternazyklische Komponenten-Abhängigkeiten!

Unterscheide:

Zyklen zur Compile-Zeit

Zyklen zur Laufzeit – z.B. durch Aufruf per Reflection

Auflösung von Zyklen

Auslagern von Funktionalität

Callback

Nachteile von ZyklenDie Komponenten eines Zyklus bilden de facto eine einzige „große Komponente“.

Hohe Koppelung zwischen den betroffenen Komponenten

Eine Änderung an einer Komponente hat i.d.R. Aus-wirkungen auf alle anderen Komponenten des Zyklus.


Statische „read“-Zyklen sind in Jigsaw verboten Compile-Fehler *

Jigsaw erlaubt jedoch Zyklen zur Laufzeit (durch reflektive Aufrufe).

Acyclic Relationships Jigsaw verbietet read-Zyklen

read

modb\module-info.java:2: error: cyclic dependence involving modarequires moda;

^1 error

read

modb moda

* Vorsicht: Compiler-Bug in 9.0.4 findet nicht alle Zyklen!


Dependency Pattern Acyclic Relationships

… mit JigsawStatische Zyklen mit requires in Modulen nicht erlaubt.

Sie führen zu Compilerfehlern *

Dynamische Zyklen zur Laufzeit (per Reflection) möglich

Patternazyklische Komponenten-Abhängigkeiten

Unterscheide:

Zyklen zur Compile-Zeit

Zyklen zur Laufzeit – z.B. durch Aufruf per Reflection

Auflösung von Zyklen

Auslagern von Funktionalität

Callback

* Vorsicht: Compiler-Bug in 9.0.4 findet nicht alle Zyklen!


Usability PatternPublished Interface

Make a module’s published interface well known


Usability Pattern Published Interface

PatternKomponente definiert ihre öffentliche Schnittstelle.

Nutzer verwenden die Komponente nur über diese Schnittstelle.

Von außen ist kein Zugriff auf die Implementierung möglich.






VorteileFördert explizite Definition von Komponenten-Grenzen

Dokumentation

Änderung der gekapselten Implementierung hat keine Auswirkung auf Nutzer.






NachteileHö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)






AbgrenzungenManche 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“


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?


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




}

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)




}

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


exports

pkg.myimpl

pkg.myapi

MyImpl

Instanzen von MyImpl behalten ihren Typ auch über Module-grenze hinaus, obwohl dessen Package nicht exportiert ist.

public class Factory {public MyInterface create() {

return new MyImpl(); }

…

public class Caller {…

MyInterface myInt = new MyFactory().create();

…

MyInterface

MyFactory

Caller

modamodb

pkga

read

Published Interface Typensichtbarkeit


exports erlaubt statische Zugriffe.

opens öffnet für „Deep Reflection“ mit setAccessible(true)

Compile-Zeit Reflection(Shallow)

Reflection(Deep)

exports pkg erlaubt erlaubt nicht erlaubt

opens pkg nicht erlaubt erlaubt erlaubt

exports pkg undopens pkg

erlaubt erlaubt erlaubt

Published Interface opens von Packages


Usability PatternSeparate Abstractions

Place abstractions and the classes that implement them

in separate modules


Usability Pattern Separate Abstractions

PatternTrenne 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.

VorteileImplementierung kann komplett ausgetauschtwerden, erlaubt späte Wahl (zur Laufzeit).

Beispiel: Datenbank-Treiber

Weitere Indirektionen

Mehr Aufwand

Höhere Komplexität, Zusammenspiel schwerer nachvollziehbar

Nachteile


Usability Pattern Separate Abstractions - 3 Ebenen

pkg.service

IService1

IService2



pkg.service

IService1

IService2

pkg.foobar

IFoo

IBar



pkg.service

IService1

IService2

pkg.foobar

IFoo

IBar

api



pkg.service.blue

Impl1

Impl2

pkg.foobar.blue

FooImpl

BarImpl

blue.impl



pkg.service.green

OtherImpl1

OtherImpl2

pkg.foobar.green

FooImpl

BarImpl

green.impl



pkg.service.red

RedImpl1

RedImpl2

red.impl



factory

client



factory

client

Auswahl der Implementierung als „ganze“ Komponente



factory

client

Auswahl der Implementierung in „Teilen“ (einmalig oder nach Bedarf)


Separate Abstractions mit Jigsaw-Modules

green.impl

red.impl

blue.impl

api

read

read

exports

read


Separate Abstractions 1. „Factory-Module“

green.impl

red.impl

blue.impl

api

factory

client


green.impl

red.impl

blue.impl

api

factory

client


read

read

read


green.impl

red.impl

blue.impl

api

factory

client


exports to

exports to

exports to

Factory muss Implementierungsklassen kennen!


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


Separate Abstractions Split-Package-Problem

green.impl

red.impl

blue.impl

api

read

read

exports

read

Vorsicht: Modules müssen disjunkte Packages haben.

Ein „Split“ eines Package auf mehrere Modules ist nicht erlaubt!

Gilt auch, wenn das Package nicht exportiert ist!!

Selbst dann, wenn es keine Klassen-Duplikate in den Modules gibt!!!


Schnittstelle java.sql.Driver Implementierungin 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.Driverwith com.mysql.jdbc.Driver;

}

Separate Abstractions 3. Dynamische Bindung

module java.sql {

…// Definiert und exportiert // Schnittstelle

uses java.sql.Driver;exports java.sql;

}


Usability Pattern Separate Abstractions

… mit JigsawTrennung in verschiedene Jigsaw-Module möglich

Split-Package beachten!

uses-provides für dynamische Bindung

zur Startzeit

per ServiceLoader

Eigene Auswahl der Implementierung möglich

PatternTrenne 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.


Usability PatternModule Facade

Facade as a coarse-grained entry point to another module’s

underlying implementation


Usability Pattern Module Facade

PatternVgl. GOF-Patterns „Facade“, „Adapter“, „Decorator“

Eine Komponente dient als zentrale Facade zu anderen Komponenten.

Abhängigkeit idealerweise nur zur Facade nötig, nicht zu den „dahinter“ liegenden Komponenten

VorteileKapselt dahinterliegende Details an zentraler Stelle

Kapselt Schnittstellen

Höhere Lesbarkeit

Einfachere Nutzung

Erzwingt Reihenfolgen

erlaubt automatische Vor- / Nach-Bearbeitung


Module Facade mit eigenen Facade-Modules

In eigenen „Facade-Modules“ kann man andere Module kapseln.


Module Facade Transitive Abhängigkeiten

module modfacade {requires modx;requires transitive mody;

}

In eigenen „Facade-Modules“ kann man andere Module kapseln.

Jigsaw ermöglicht auch, Abhängigkeiten transitiv weiterzugeben.


1-transitiv 2-transitiv

Module Facade Transitive Abhängigkeiten


Usability Pattern Module Facade

… mit Jigsawrequires transitivein module-info reicht Abhängigkeit automatisch weiter

Ermöglicht leere Aggregator-Modules

Ermöglicht nicht die Kapselung „dahinter“ liegender APIs: Im Gegenteil werden diese ja durchgereicht!

PatternVgl. GOF-Patterns „Facade“, „Adapter“, „Decorator“

Eine Komponente dient als zentrale Facade zu anderen Komponenten.

Abhängigkeit idealerweise nur zur Facade nötig, nicht zu den „dahinter“ liegenden Komponenten


Utility PatternTest Module

Each module should have a corresponding test module that

validates it’s behavior …


Utility Pattern Test Module

PatternZu 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

VorteileKomponenten sind unabhängig voneinander testbar, Fehler leichter lokalisierbar

Dokumentation der Nutzung der Schnittstelle

Hoher Aufwand durch Mocks

Nachteile


read

pkg blacktest

moda.test.black

Blackbox-Tests werden in separates Jigsaw-Module ausgelagert.

Dieses Testmodule benötigt keinen Zugriff auf interne Klassen.

Test Module Blackbox-Tests

pkgainternal

exports

moda

pkga


pkgainternal

pkgainternal

…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“.


Utility Pattern Test Module

… mit JigsawBlackbox als eigenes Test-Module gegen öffentliche API, Abhängigkeiten per Mocks

Whitebox: Testcode auslagern und „reinpatchen“

Integrationstests gegen öffentliche API ohne Mocks

PatternZu 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


Dependency PatternsLevelize 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


Komponenten sortieren sich in Schichten/Säulen ein.

Säule2

Säule3 …

Säule1

SchichtAnwendungskern

SchichtPersistenz

SchichtPräsentation

Component

Component

Component

Component

Component

Component

Component

Component

Component

Component

Component

Component


Jigsaw-Modules als gerichteter Graph

… mit JigsawJigsaw 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.


Jigsaw-Modules als gerichteter Graph … im Build

… mit JigsawDen Module-Graph sollte auch Build/Deployment/Test berücksichtigen.

Die Graph-Abbildung unterstützt bereits Maven / Gradle (Modellierung von Abhängig-keiten; keine Zyklen erlaubt).

Nur Teil-Build/DeploymentTest notwendig bei Änderungen von Modulen der „unteren“ Stufen.


Module-Layer für Laufzeitgruppierung

Jigsaw erlaubt Laufzeit-Grupp-ierung mit „Module-Layer“.

Layer funktioniert ähnlich wie ein Container.

Per Default: Alles im Boot-Layer

Keine gute Unterstützung für Schichten/Säulen (Calls nur per Reflection über Layergrenzen)

… mit Jigsaw


Module-Layer für Laufzeitgruppierung

Umgeht aber andere Einschränkungen

Kein Split-Package bei Geschwister-Layern

Module in verschiedenen Versionen nutzbar, wenn mit CL / Layer getrennt

Komplexes Zusammenspiel von Configuration, Classloader, Layer

… mit Jigsaw


Wo gibt esDokumentation?


Homepage Project Jigsaw

OpenJDK: JDK 9

Oracle: JDK 9 Documentation

Jigsaw-Issues

Specification (2015)

State of the Module System (2016)

Quickstart Guide

JSR376

JEPs

200 „The modular JDK“

220 „Modular Runtime Images“

260 „Encapsulate Most Internal APIs“

Mailinglisten

jigsaw-dev, jdk9-dev, jpms-spec-comments, jpms-spec-experts, jpms-spec-observers

261 „Module System“

275 „Modular Java App. Packaging“

282 „jlink: The Java Linker“

http://mail.openjdk.java.net/mailman/listinfo

http://openjdk.java.net/projects/jigsaw/

http://openjdk.java.net/projects/jdk9/

https://docs.oracle.com/javase/9/

http://openjdk.java.net/projects/jigsaw/spec/issues/

http://openjdk.java.net/projects/jigsaw/spec/reqs/

http://openjdk.java.net/projects/jigsaw/spec/sotms/

http://openjdk.java.net/projects/jigsaw/quick-start

https://www.jcp.org/en/jsr/detail?id=376

http://openjdk.java.net/jeps/<NR>

Jigsaw-Dokumentation zum Nachlesen

http://mail.openjdk.java.net/mailman/listinfo/jigsaw-dev

http://mail.openjdk.java.net/mailman/listinfo/jdk9-dev

http://mail.openjdk.java.net/mailman/listinfo/jpms-spec-comments

http://mail.openjdk.java.net/mailman/listinfo/jpms-spec-experts

http://mail.openjdk.java.net/mailman/listinfo/jpms-spec-observers

http://openjdk.java.net/projects/jigsaw/

http://openjdk.java.net/projects/jdk9/

https://docs.oracle.com/javase/9/

http://openjdk.java.net/projects/jigsaw/spec/issues/

http://openjdk.java.net/projects/jigsaw/spec/reqs/

http://openjdk.java.net/projects/jigsaw/spec/sotms/

http://openjdk.java.net/projects/jigsaw/quick-start

https://www.jcp.org/en/jsr/detail?id=376

http://openjdk.java.net/jeps/0

Copyright © Accso – Accelerated Solutions GmbH 72https://twitter.com/ThePracticalDev/status/763470048463912960

https://twitter.com/ThePracticalDev/status/763470048463912960


Als PDF-Download bei http://accso.de/java/

JavaSPEKTRUM-Sonderdruck

heise/iX Sonderheft

„Java 2017“

Accso – Accelerated Solutions GmbHT | +49 6151 13029-0E | [email protected]@ | www.accso.de

Berliner Allee 58 | 64295 DarmstadtMoltkestraße 131a | 50674 KölnBalanstraße 55 | 81541 München

http://accso.de/java/


GithubBeispiele


https://github.com/accso/java9-jigsaw-examples/

Läuft mit Java Release-Build b181 und 9.0.1, 9.0.4 und JDK 10

Bash-Skripte für Compile, Run, Test (in Windows z.B. mit Babun nutzbar)

Projektstrukturen für Eclipse 4.7.3 Oxygen.3

Unsere 32 Beispiele zeigen alles Wissenswerte zu Jigsaw zu Requires, Exports, Exports-To, Requires-Static, Requires-Transitive, Blackbox-Test, Whitebox-Test, Uses, Provides, Maven-Integration, Opens, Open Module, Manifest-Optionen, versteckte Main-Klasse, Automatic Modules, Reflection, Resolved Modules (Configuration), Naming von Modulen, Unnamed Module (Classpath), Layer, Javadoc, Annotations, jlink etc. pp. usw. usf.

Unsere Jigsaw-Beispiele stehen auf Github






Accso – Accelerated Solutions GmbHT | +49 6151 13029-0E | [email protected]@ | www.accso.de

Berliner Allee 58 | 64295 DarmstadtMoltkestraße 131a | 50674 KölnBalanstraße 55 | 81541 München

https://speakerdeck.com/mrtnlhmnn

@accso@mrtnlhmnn @krschaal


https://github.com/accso/java9-jigsaw-depvis/


https://speakerdeck.com/mrtnlhmnn


https://github.com/accso/java9-jigsaw-depvis/


Documents

Modularity-Patterns mit Java 9 / JigsawProject Jigsaw seit Java 9-Release vom 21. September 2017 enthalten. Aktuell: Releases 9.0.4 und 10.0.1. JEP 261, 200, 201, 220, 260, 282 mit