The article "JDK 9 und die Plattformmodularisierung - Die Stichsäge kommt voran" was published in the German Javamagazin 1.2016 and describes the current snapshot of project Jigsaw with the Java platform modularization in the JDK 9 early access release build 83. Examples of the current tool set are included, like jdeps, jimage and jlink as of JDK 9 EA b83. Please be aware of newer JDK 9 early access release builds and the changed proposed JDK 9 release schedule. The proposed date for JDK 9 general availability should be expected in late march 2017 but always check first JDK 9 release schedule at http://openjdk.java.net/projects/jdk9/

1. magazinJava • Architekturen• Web • Agile www.javamagazin.de
Österreich €10,80 Schweiz sFr 19,50 Luxemburg €11,15Deutschland €9,80
JavaMag
1.2016
Vert.x im Produktionsbetrieb 73
Programminfos
ab Seite 36!
Java trifft SAP
Umgang mit Geschäftsentitäten 92
Jigsaw
JDK 9 und die Modularisierung 24
© iStockphoto.com/bubaone© iStockphoto.com/timoph
Planet
Android
Mit HTTP/2 und REST
kommunizieren 106
Wie schneide ich
Microservices 89
Frischer Wind
durch JavaFX 46
Die Möglichkeiten – und die Grenzen
23. – 24. Februar 2016
Courtyard by Marriott München City Ost
www.devops-training.de
Das Thema Docker sorgt gerade für viel Aufsehen.
Ob kleine Start-ups oder große Firmen – schon
aufregend viele Unternehmen setzen auf die Open-
Source-Technologie Docker. Aber was hat es mit
dieser Art von Containern auf sich, die den Vir-
tualisierungsmarkt aufrollen und die Softwareent-
wicklung nachhaltig verändern wollen? Docker
verspricht einen schnellen Start, flexible Konfigu-
ration und stabile Images für Entwicklung und Pro-
duktion. In diesem Docker Camp wollen wir diesen
Versprechen praktisch nachgehen. Wir starten mit
einem Überblick und stellen die ersten Schritte
beim Einsatz von Docker vor.
Sie lernen die wichtigsten Befehle, Anweisungen
und Konzepte praktisch kennen. Anhand eines
ausführlichen Beispiels zeigen wir, wie ein Micro-
service implementiert, mit Docker installiert und
in einer Umgebung mit anderen Services integ-
riert wird. Außerdem diskutieren wir das aktuelle
Docker-Ökosystem und klären über Chancen und
Risiken auf. Dieses Camp vermittelt Ihnen die
Docker-Grundlagen in nachvollziehbaren Schritten
und versetzt Sie in die Lage, anschließend selbst
zu entscheiden, ob und wie Docker im eigenen
Unternehmens- und IT-Kontext sinnvoll einsetzbar
ist. Dieses Camp sollten Sie nicht verpassen!
Ihr Trainer:
Peter Roßbach
Veranstalter:
Präsentiert von:
NIchTveRPasseN!FRÜHBUCHERPREISE
BIS 28. JANUARSICHERN!
JavaMagazin1.2016 AndroidJigsawVert.xMicroservicesFregeJavaFXJava-/SAP-IntegrationHTTP/2

2. javamagazin 1|2016
Java Core Jigsaw
24 www.JAXenter.de
von Wolfgang Weigend
Das Projekt Jigsaw hat die primäre Aufgabe, das Design
und die Implementierung eines Standardmodulsystems
für die Java-Plattform und für das JDK 9 bereitzustellen.
Jigsaw soll außerdem berücksichtigen, dass sich die Ja-
va-SE-Plattform und das JDK auch für kleine Endgeräte
durchgängig, dynamisch und einfach anpassen lassen.
Zudem soll die Sicherheit und Wartbarkeit von Java-SE-
Plattformimplementierungen und vom JDK verbessert
werden. Insbesondere sind die Probleme beim Umgang
mit dem Classpath und dem monolithischen JDK abzu-
schaffen.
Mit drei JDK Enhancement Proposals (JEPs) wurden
Basisvorschläge für die JDK-Modularität gemacht: mo-
dulare JDK-Struktur (JEP 200 – The Modular JDK [1]),
modulare Reorganisation vom JDK-Sourcecode
(JEP 201 – Modular Source Code [2]), Restrukturierung
von JDK- und JRE-Laufzeit-Images (JEP 220 – Modular
Run-Time Images [3]). Die Java-SE-9-Spezifikationsan-
forderung (JSR 376: Java Platform Module System [4])
spezifiziert das gesamte Modulsystem [5] für die Java-
SE-Plattform.
Modulares JDK (JEP 200): JDK modular aufspalten
Bei der Definition der modularen JDK-Struktur verfolgt
man das Ziel, das JDK in verschiedene Module aufzu-
spalten, die zur Kompilation für Build und Installati-
on oder in unterschiedlichen Laufzeitkonfigurationen
wieder zusammengefügt werden können. Die Modul-
Das für September 2016 geplante Erscheinungsdatum vom JDK 9 soll den lang
ersehnten modularen Aufbau der Java SE enthalten. Damit ist es künftig möglich,
die technische Paketierung von ausgewählter Java-Funktionalität selbst zu be-
stimmen. Dafür müssen Entwickler aber genau wissen, wie Module erstellt und
kompiliert werden.
© iStockphoto.com/Nikola_Nastasic
Die Stichsäge kommt
voran
JDK 9 und die Plattformmodularisierung

3. javamagazin 1 |2016
Java CoreJigsaw
25www.JAXenter.de
konfigurationen korrespondieren jeweils mit der voll-
ständigen Java-SE-Plattform, der kompletten JRE und
dem gesamten JDK. Zudem sind die Konfigurationen
inhaltlich nahezu gleichwertig mit den drei Compact-
Profilen der Java SE 8. Eigene Konfigurationen ent-
halten lediglich einen Modulsatz und durchgereichte
Modulanforderungen. Die Modulstrukturdefinition un-
terscheidet zwischen Standardmodulen, deren Spezifika-
tionen der Java Community Process (JCP) überwacht,
und solchen Modulen, die spezifisch für das JDK sind.
Außerdem werden Module unterschieden, die in die
Java-SE-Plattformspezifikation einbezogen werden und
damit für jede Plattformimplementierung obligatorisch
sind. Zur Umsetzung des Modulsystemvorschlags wur-
den folgende Annahmen getroffen:
• Ein Modul enthält Java-Klassendateien, Ressourcen,
abhängige native Bibliotheken und Konfigurations-
dateien.
• Jedes Modul trägt einen Namen.
• Ein Modul kann von einem oder mehreren anderen
Modulen abhängig sein.
• Ein Modul kann alle Public-Typen in ein oder mehre-
re API-Packages exportieren, das darin enthalten ist.
Damit werden die Typen für abhängigen Modulcode
nutzbar gemacht und auch für Kodierungen, die nicht
in jedem Modul verwendet werden.
• Die Einschränkung von Modulen geschieht über den
Namen und über die Modulgruppe, in die die Public-
Typen und deren API-Packages exportiert werden.
Dies ermöglicht den Modulen, ihre internen Imple-
mentierungsinterfaces weiterzureichen, ohne dabei
diese Interfaces allen anderen Kodierungen zeigen zu
müssen.
• Ein Modul kann die Public-Typen weiterexportieren,
die von einem oder mehreren Modulen exportiert
wurden und davon abhängig sind. Dadurch können
Module nach einer bestimmten Zeit umgestaltet
werden und die exportierten Public-Type-Gruppen
dabei erhalten bleiben. Dazu werden Aggregator-
Moduldefinitionen angeboten, die alle exportierten
Public-Typen von abhängigen Modulgruppen auf-
sammeln können.
Die vorgeschlagene Modulstruktur unterliegt folgenden
Implementierungsrichtlinien:
• Die Namen von Standardmodulen müssen mit der
Zeichenkette java. beginnen, und alle anderen im
JDK enthaltenen Module müssen mit der Zeichen­
kette jdk. beginnen.
• Falls ein Modul einen Typ exportiert, der einen
­Public oder Protected Member enthält, der wiederum
auf den Typ eines anderen Moduls verweist, so muss
das erste Modul den Public Type vom zweiten Modul
wieder exportieren. Dadurch wird die Arbeitsweise
einer Method-Invocation-Kette sichergestellt.
• Ein Standardmodul kann Standard- und Non-Stan-
dard-API-Packages enthalten und beliebige Standard-
API-Packages ohne Beschränkungen exportieren.
Der Export von API-Packages kann auch zu einer
Auswahl von Standard- und Non-Standard-Modulen
erfolgen. Im Umkehrschluss müssen aber keine Non-
Standard-API-Packages exportiert werden. Falls ein
Java-SE-Modul verwendet wird, um es beispielsweise
als Vorschlag in die Java-SE-Plattformspezifikation
einzubinden, muss es keine Non-SE-API-Packages
exportieren.
• Ein Standardmodul kann von einem oder mehreren
anderen Standardmodulen abhängen und es muss
keine Public-Typen von Non-SE-Modulen wieder
rückexportieren. Falls ein Java-SE-Modul vorliegt,
muss es keine Public-Typen von Non-SE-Modulen
reexportieren. Aus dieser und der vorangegangenen
Richtlinie ergibt sich die Konsequenz, dass Code, der
nur von Java-SE-Modulen abhängt, auch nur von
Java-SE-Typen abhängig ist und damit für alle Java-
SE-Plattformimplementierungen portierbar ist.
• Ein Non-Standardmodul muss keine Standard-API-
Packages exportieren und es darf die Public-Typen,
die von einem Standardmodul exportiert wurden,
wieder reexportieren.
JDK-Modulgraph visualisiert Module
Die modulare JDK-Struktur kann als Graph visualisiert
werden. Dabei wird jedes Modul als Knoten dargestellt.
Mit einem vollständigen Graphen wird jeder Modul-
knoten mit einem anderen Modulknoten durch eine
Kante verbunden, wenn das erste Modul vom zweiten
Modul abhängt. Der komplette Modulgraph hat zu vie-
le Kanten, um sie noch übersichtlich darstellen zu kön-
nen. Deshalb werden die redundanten Kanten durch
transitive Reduktion vom Modulgraphen ausgelassen.
Die Java-SE-Module sind mit der Farbe Orange dar-
gestellt und die Non-SE-Module mit blauer Farbe. Falls
ein Modul von einem anderen Modul abhängt und des-
sen Public-Typen reexportiert, ist die Kante vom ersten
zum zweiten Modul dunkel. Im umgekehrten Fall ist
Die verschiedenen JDK-Module lassen sich zur Kompilation
für Build und Installation oder in unterschiedlichen Laufzeit-
konfigurationen wieder zusammenfügen.

4. javamagazin 1|2016
Java Core Jigsaw
26 www.JAXenter.de
die Kante heller. An der Unterseite befindet sich das
Modul java.base mit essenziellen Klassen wie java.
lang.Object und java.lang.String. Das Base-Modul
hängt von keinem Modul ab, und alle anderen Module
sind vom Base-Modul abhängig. An der Oberseite be-
findet sich das Modul java.se. Es umfasst alle Module
der Java-SE-Plattform und ist ein Beispiel eines Aggre-
gatormoduls, das die Reexporte und Inhalte von ande-
ren Modulen aufsammelt, aber keine eigenen Inhalte
hinzufügt. Ein konfiguriertes Laufzeitsystem mit dem
Modul java.se enthält auch alle Java-SE-Plattform-API-
Packages. Ein Modul wird nur dann als Vorschlag zur
Java-SE-Plattformspezifikation hinzugefügt, wenn es
sich um ein Standardmodul handelt, das vom ja­va. se-­
Modul auch erreichbar ist. Die Aggregatormodule
ja­va.com­pact1, java.compact2 und java.compact3 im-
plementieren die Java-SE-Compact-Profile. Es existiert
auch ein Non-Standard-Modul jdk.compact3, weil ein
compact3 JDK Build einige Non-SE-API-Packages ent-
hält, die in den anderen Compact Profile Builds nicht
enthalten sind.
Die anderen Non-Standard-Module enthalten De-
bugger- und Servicewerkzeuge sowie APIs wie jdk.jdi,
jdk. jcmd und jdk.jconsole in der oberen linken Dia-
grammhälfte. Die Entwicklungswerkzeuge jdk.compi-
ler, jdk.javadoc und jdk.xml.bind sind in der oberen
rechten Diagrammhälfte dargestellt. Andere Service-
Provider, wie jdk.charsets, jdk.scripting.nashorn und
jdk.crypto.ec, werden über die Konvention java.util.Ser-
viceLoader den anderen Modulen zugänglich gemacht.
Der Modulgraph ist praktisch eine Art Schnittstelle
und wird auch als solche spezifiziert und erweitert. Der
Graph, der unterhalb vom Graphmodul java.se liegt,
bei dem alle Non-SE-Module und korrespondierenden
Kanten entfernt wurden, wird zur Aufnahme in die
Java-SE-Plattformspezifikation vorgeschlagen und die
Weiterentwicklung über den Java-Community-Prozess
gesteuert. Die Fortentwicklung vom restlichen Graphen
wird durch künftige JDK Enhancement Proposals ab-
gedeckt. Wird ein Modul so spezifiziert, dass es allge-
mein verwendet werden kann, unterliegt es in jedem Fall
den gleichen evolutionären Beschränkungen wie andere
APIs. Werden solche Module entfernt oder inkompati-
bel verändert, so erfordert dies eine öffentliche Benach-
richtigung für ein Hauptrelease im Voraus.
Modularer Quellcode (JEP 201): Quellcode komplett
umstrukturieren
Durch die modulare Reorganisation vom JDK-Source-
code, der Build-System-Verbesserung zum Kompilieren
von Modulen und mit einer erzwungenen Modulab-
grenzung zum Build-Zeitpunkt wird die existierende
JDK-Quellcodeorganisation komplett neu gestaltet. Das
neue Schema des modularen JDKs nutzt die seltene Ge-
legenheit einer kompletten Quellcodeumstrukturierung,
um die Wartung zu vereinfachen. Der Implementie-
rungsvorschlag sieht das Schema in jedem JDK Forest
Repository vor, mit Ausnahme der Java HotSpot VM.
Das Schema sieht in Kurzform wie folgt aus:
src/$MODULE/{share,$OS}/classes/$PACKAGE/*.java
native/include/*.{h,hpp}
$LIBRARY/*.{c,cpp}
conf/*
• $MODULE ist der Modulname (z. B. java.base).
• Das Verzeichnis share enthält, wie zuvor, verteilte
und plattformübergreifende Kodierungen.
• Das Verzeichnis $OS enthält betriebssystemspezifi-
sche Kodierungen und steht für die Betriebssysteme
Unix, Windows etc.
• Das Verzeichnis classes enthält die Java-Quell- und
Ressourcendateien, die im Verzeichnisbaum struktu-
riert sind, inklusive ihrer API-$PACKAGE-Hierar-
chie.
• Das Verzeichnis native enthält C- oder C++-Quell-
dateien, wie zuvor, aber mit unterschiedlicher Orga-
nisationsstruktur: Das Verzeichnis include enthält
C- oder C++-Header-Dateien, die für externe An-
wendungen exportiert werden können (z. B. jni.h).
Die C- oder C++-Quelldateien, die als Shared Library
oder DLL bezeichnet werden und in die kompilierter
Code gelinkt werden, sind im Verzeichnis $LIBRA-
RY enthalten (z. B. libjava oder libawt).
Abb. 1: JDK-Modulgraph visualisiert jedes Modul als Knoten

5. www.JAXenter.de
• Das Verzeichnis conf enthält Konfigurationsdateien, die der Benutzer editieren
kann (z. B. net.properties).
Build-System-Änderungen: Module zu einem Zeitpunkt kompilieren
Das Build-System wird so verändert, dass ein Modul zu einem Zeitpunkt kom-
piliert werden kann, im Gegensatz zu einem Repository. Die Module werden
passend zur umgekehrten Anordnungsreihenfolge vom Modulgraphen kompi-
liert. Unabhängige Module werden nach Möglichkeit gleichzeitig kompiliert.
Der Nebeneffekt einer Modulkompilierung, im Gegensatz zu den Repositories,
besteht darin, dass der Repository-Code von corba, jaxp und jaxws neue Ja-
va-Sprachmerkmale und APIs verwenden kann. Das war bislang nicht zulässig,
da diese Repositories vor dem JDK Repository kompiliert wurden. Die kom-
pilierten Klassen in einem Interims-Build (Non-Image) werden in Module auf-
geteilt. Dann wird aus jdk/classes/*.class im überarbeiteten Build-System jdk/
modules/$MODULE/*.class erzeugt. Die Image-Build-Struktur wird nicht ver-
ändert, und es wird nur minimale inhaltliche Unterschiede geben. Die Modul-
grenzen werden bestenfalls vom Build-System zum Build-Zeitpunkt gesetzt. Falls
Modulabgrenzungen verletzt werden, schlägt der Build-Lauf fehl. Mit der Konfi-
gurationsdatei modules.xml werden die Abgrenzungen definiert und neben dem
Quellcode gewartet. Dateiänderungen verlangen eine Überprüfung der Projekt-
Committer von Jigsaw.
Modulare Laufzeit-Images (JEP 220)
Der Vorschlag besteht aus der Umstrukturierung von JDK und JRE-Laufzeit-Ima-
ges in passende Module und der Verbesserung von Geschwindigkeit, Sicherheit
und Wartbarkeit. Zur Namensgebung von Modulen, Klassen und Ressourcen,
die im Laufzeit-Image gespeichert sind, soll ein neues URI-Schema definiert wer-
den, ohne dabei die interne Struktur oder das Image-Format offenzulegen. Vor-
handene Spezifikationen sollen überarbeitet werden, um diese Änderungen zu
erreichen. Dafür wurden im Anschluss diese Ziele gesetzt:
• Schaffung eines Laufzeitformats zur Speicherung von Klassen- und Ressour-
cendateien mit den folgenden Eigenschaften: Es soll zeit- und platzsparender
sein als das veraltete jar-Format, das auf dem zip-Format basiert. Es kann
Klassen- und Ressourcendateien auf Modulebene lokalisieren und laden. Es
kann Klassen- und Ressourcendateien speichern, die aus den Modulen vom
JDK, Bibliotheken und Applikationen stammen.
• Es kann zur Anpassung von zusätzlich anfallenden Daten erweitert werden,
wie für vorab berechnete JVM-Datenstrukturen und präkompilierten nativen
Code für Java-Klassen.
• Restrukturierung vom JDK und JRE-Laufzeit-Images, um zu trennen, ob Da-
teien von Entwicklern, Deployment-Administratoren und Benutzern verwen-
det werden, die sie auch angemessen modifizieren können. Oder im Gegensatz
dazu sollen interne Implementierungsdateien ohne Benachrichtigung geändert
werden können.
• Unterstützung zur Ausführung von gemeinsamen Operationen, die bislang
nur mithilfe von internen Strukturuntersuchungen des Laufzeit-Images ge-
macht wurden, wie die Aufzählung aller vorhandenen Image-Klassen.
• Bereitstellen einer selektiven Privilegienaufspaltung von JDK-Klassen, die
bislang alle Sicherheitsberechtigungen besitzen, diese aber tatsächlich nicht
benötigen.
• Bewahrung der existierenden Verhaltensweise von mustergültigen Anwen-
dungen, die beispielsweise von internen JRE- und JDK-Aspekten der Laufzeit-
Images unabhängig sind.
Laufzeit-Image-Struktur: Trennung aufheben
Die bisherige Trennung von JRE und JDK ist historisch bedingt eine Konse-
quenz aus der späten Implementierungsentscheidung bei der Entwicklung vom
Anzeige

6. javamagazin 1|2016
Java Core Jigsaw
28 www.JAXenter.de
JDK 1.2, die niemals überarbeitet wurde. Die neue
Image-Struktur wird diese Trennung aufheben, und
dann wird ein JDK-Image ein einfaches Laufzeit-Image
sein, das den vollständigen Satz von Entwicklungs-
werkzeugen sowie andere historische JDK-Elemente
enthalten wird. Das modulare Laufzeit-Image besitzt
folgende Verzeichnisse:
• Das Verzeichnis bin enthält jegliche Kommandozei-
len-Launcher von den Modulen, die in das Image
gebunden wurden. Für Windows werden weiterhin
die zur Laufzeit dynamisch gebundenen nativen Bib-
liotheken enthalten sein.
• Das Verzeichnis conf enthält die Dateien .properties,
.policy und andere Dateiarten, die von Entwicklern,
Deployment-Administratoren und Benutzern editiert
werden können, die bislang im Verzeichnis lib und
seinen Unterverzeichnissen zu finden waren.
• Das Verzeichnis lib bei MAC OS oder das Verzeich-
nis lib/$ARCH bei Linux und Solaris wird die zur
Laufzeit dynamisch gebundenen nativen Bibliotheken
enthalten. Sie können mit Programmen gelinkt wer-
den, die über integrierte Laufzeitumsysteme verfügen.
• Im Verzeichnis lib müssen alle anderen Dateien und
Unterverzeichnisse als private Implementierungsde-
tails des Laufzeitsystems behandelt werden. Sie sind
nicht zur externen Verwendung bestimmt, und deren
Namen, Format und Inhalt kann ohne Ankündigung
geändert werden.
• Das vollständige JDK-Image enthält die Verzeichnisse
demo, sample, man, und include.
• Das Root-Verzeichnis vom modularen Laufzeit-
Image wird die notwendigen Dateien COPYRIGHT,
LICENSE, README und release enthalten. Um
festzustellen, welches Modul sich im Laufzeit-Image
befindet, wird die Datei release mit der neuen Eigen-
schaft MODULES erweitert, die aus einer Modulna-
menliste besteht, jeweils getrennt durch Leerzeichen.
Die Liste wird topologisch angeordnet, passend zu
den Modulabhängigkeitsbeziehungen, sodass das
Modul java.base immer zuerst aufgelistet wird.
Ausgeschlossene Mechanismen und Bereiche
Der Java-Endorsed-Standards-Override-Mechanismus
wird entfernt, wie bereits in der Java-SE-8-Dokumen-
tation ersichtlich und im JEP 220 erwähnt wurde [3].
Ein modulares Image besteht aus Modulen und weni-
ger aus jar-Dateien. Künftig wird erwartet, dass die
Endorsed-Standards und Standalone-APIs nur noch
in modularer Form unterstützt werden, über das
Upgradeable-Mo­dules-­Konzept. Falls ein JDK-Modul
einen Endorsed-Standard oder ein Standalone-API
Verzeichnisse vom bootmodules.jimage
■■ java.activation
■■ java.annotations.common
■■ java.base
■■ java.compact1
■■ java.compact2
■■ java.compact3
■■ java.compiler
■■ java.corba
■■ java.datatransfer
■■ java.desktop
■■ java.instrument
■■ java.logging
■■ java.management
■■ java.naming
■■ java.prefs
■■ java.rmi
■■ java.scripting
■■ java.se
■■ java.security.jgss
■■ java.security.sasl
■■ java.smartcardio
■■ java.sql
■■ java.sql.rowset
■■ java.transaction
■■ java.xml
■■ java.xml.bind
■■ java.xml.crypto
■■ java.xml.ws
■■ javafx.base
■■ javafx.controls
■■ javafx.fxml
■■ javafx.graphics
■■ javafx.media
■■ javafx.swing
■■ javafx.web
■■ jdk.accessibility
■■ jdk.attach
■■ jdk.charsets
■■ jdk.compiler
■■ jdk.crypto.ec
■■ jdk.crypto.mscapi
■■ jdk.crypto.pkcs11
■■ jdk.deploy
■■ jdk.hotspot.agent
■■ jdk.httpserver
■■ jdk.internal.le
■■ jdk.internal.opt
■■ jdk.jartool
■■ jdk.javadoc
■■ jdk.javaws
■■ jdk.jcmd
■■ jdk.jconsole
■■ jdk.jdeps
■■ jdk.jdi
■■ jdk.jdwp.agent
■■ jdk.jfr
■■ jdk.jlink
■■ jdk.jvmstat
■■ jdk.localedata
■■ jdk.management.cmm
■■ jdk.naming.dns
■■ jdk.naming.rmi
■■ jdk.pack200
■■ jdk.plugin
■■ jdk.plugin.dom
■■ jdk.policytool
■■ jdk.rmic
■■ jdk.scripting.nashorn
■■ jdk.scripting.nashorn.shell
■■ jdk.sctp
■■ jdk.security.auth
■■ jdk.security.jgss
■■ jdk.snmp
■■ jdk.xml.bind
■■ jdk.xml.dom
■■ jdk.xml.ws
■■ jdk.zipfs

7. javamagazin 1 |2016
Java CoreJigsaw
29www.JAXenter.de
implementiert, muss es möglich sein, eine Modulver-
sion von einem späteren Release in beliebiger Phase
zu verwenden, z. B. zum Compile-Zeitpunkt, zum
Build-Zeitpunkt oder zur Laufzeit. Deshalb wird vor-
geschlagen, die System-Property java.endorsed.dirs,
das Verzeichnis lib/endorsed und die Codemechanis-
musimplementierung zu entfernen. Um festzustellen,
wo dieser Mechanismus benutzt wurde, werden der
Compiler und der Launcher so modifiziert, dass er
fehlschlägt, wenn SystemProperty gesetzt wurde oder
das Verzeichnis lib/endorsed existiert.
Der Extension-Mechanismus zur Unterstützung von
optionalen Packages wird ebenfalls entfernt, wie bereits
in der Java-SE-8-Dokumentation ersichtlich und im
JEP 220 erwähnt wurde [3]. Einige nützliche Merkmale,
die dem Extension-Mechanismus zugeordnet sind, blei-
ben dennoch bestehen:
• Das Class-Path-Manifest-Attribut, das die jar-Da­tei­
en­abhängigkeit untereinander spezifiziert.
• Die Manifest-Attribute {Spe­ci­fi­ca­tion,Im­ple­men­ta­
tion}-{Title,Ver­sion,Vendor}, welche die Package-
und die jar-Dateiversionsinformation spezifizieren.
• Das Sealed-Manifest-Attribut, das ein Package oder
eine jar-Datei versiegelt.
• Der Extension Class Loader wird aus Kompatibili-
tätsgründen beibehalten.
Auch rt.jar und tools.jar werden entfernt. Die Klassen-
und Ressourcendateien, die ehemals in lib/rt.jar, lib/
tools.jar, lib/dt.jar und in zahlreichen anderen internen
jar-Dateien gespeichert wurden, werden jetzt in einem
besser geeigneten Format in implementierungsspezifi-
schen Dateien im lib-Verzeichnis abgelegt. Das Datei-
format wird nicht weiter spezifiziert und kann jederzeit
geändert werden.
Java-Plattform-Modulsystem (JSR 376): Einfach und
verständlich
Die Spezifikation definiert ein tragfähiges und ska-
lierbares Modulsystem für die Java-Plattform. Es soll
verständlich und einfach nutzbar sein, damit die Ent-
wickler das Modulsystem zum Aufbau und der War-
tung von Bibliotheken sowie für große Java-SE- und
Java-EE-Anwendungen verwenden können. Die Ska-
lierbarkeit steht im Vordergrund, damit sie zur Modu-
larisierung der Java-SE-Plattform selbst beiträgt und für
deren Implementierungen taugt. Das Einsatzgebiet von
Java SE 9 umfasst Embedded-Geräte, Laptops, Desk-
tops und Server. Existierende Spezifikationen, wie die
Java-Language-Spezifikation (JLS), die Java-Virtual-
Machine-Spezifikation (JVMS) und andere Elemente
der Java-SE-Plattform-Spezifikation werden durch den
JSR 376 überarbeitet und aktualisiert. Im Dokument
„The State of the Module System – Initial Edition“ [6]
sind die Erweiterungen der Java-SE-Plattform mit dem
Jigsaw-Prototyp von Mark Reinhold beschrieben und
dienen als Einstiegspunkt für den JSR 376.
Jigsaw-Installation und -Werkzeuge
Das Project Jigsaw wurde zu diesem Zeitpunkt noch
nicht mit dem JDK 9 zusammengeführt, sodass es bis-
lang eigenständige JDK 9 Early Access Software Builds
mit und ohne Jigsaw gibt. Das Release „JDK 9 Early
Access with Project Jigsaw, build b83“ steht per Down-
load [7] und als zip-Datei [8] für die Betriebssysteme
Windows, OS X, Linux und Solaris zur Verfügung. Die
Datei jigsaw-jdk-bin-windows-i586.zip für Windows
32 Bit muss in ein Verzeichnis entpackt werden und
meldet sich wie folgt:
C:projectsjdk1.9.0>java -version
java version "1.9.0-ea"
Java(TM) SE Runtime Environment (build 1.9.0-ea-jigsaw-nightly-h3477-
20150929-b83)
Java HotSpot(TM) Client VM (build 1.9.0-ea-jigsaw-nightly-h3477-
20150929-b83, mixed mode)
Vergleicht man das lib-Verzeichnis ..jdk1.9.0libmo-
dules mit der Version „JDK 9 EA Build 85“ und der
Version „JDK 9 EA Jigsaw Build 83“, sind beim JDK 9
EA b85 im Pfad C:Program Files (x86)Javajdk1.9.0
libmodules die Modul-Images appmodules.jimage,
bootmodules.jimage und extmodules.jimage enthalten.
Beim JDK 9 EA Jigsaw b83 ist im Verzeichnis C:pro-
jectsjdk1.9.0libmodules nur das Modul-Image boot-
modules.jimage enthalten. Über das Werkzeug jimage
werden die Klassendateien vom bootmodules.jimage im
Pfad C:projectsjdk1.9.0libmodules angezeigt.
jimage list bootmodules.jimage more und über die
Eingabe jimage extract bootmodules.jimage -dir werden
die Verzeichnisse mit den jeweils darin enthaltenen Da-
teien module-info.class in das frei wählbare Verzeichnis
C:projectsjdk1.9.0mydir geschrieben (Kasten: „Ver-
zeichnisse vom bootmodules.jimage“).
Mit dem jdeps-Werkzeug können die abhängigen
Module aufgelistet werden, die eine besondere Class-
path-Abhängigkeit besitzen. Diese Informationen wer-
den gebraucht, um die benötigten Module automatisch
zu bestimmen, die der Default-Einstellung entsprechen.
Wird diese Erkennungsoption explizit ausgeschaltet,
muss man stattdessen dem gesamten Image vertrau-
en oder einen eigenen Modulsatz spezifizieren. Das
kommt nur dann zur Ausführung, wenn JMODs zur
Laufzeit für den Java-Packager gebraucht werden. Un-
Künftig wird erwartet, dass die
Endorsed-Standards und Stand­
alone-APIs nur noch in modularer
Form unterstützt werden.

8. javamagazin 1|2016
Java Core Jigsaw
30 www.JAXenter.de
ter dem provisorischen Begriff „JMOD“ versteht man
ein neues künstliches Format, das über die Definition
von jar-Dateien hinausgeht. Darin enthalten sind na-
tiver Java-Code, Implementierungsdateien und andere
anfallende Daten, die bislang nicht in jar-Dateien hin-
einpassten.
Schaut man sich die Modulklassenabhängigkeiten
vom Verzeichnis java.desktop mit dem Java Class De-
pendency Analyzer jdeps an, so liefert jdeps -s eine Zu-
sammenfassung der Abhängigkeiten:
C:projectsjdk1.9.0mydirjdeps -s java.desktop
java.desktop - java.base
java.desktop - java.datatransfer
java.desktop - java.prefs
java.desktop - java.xml
C:projectsjdk1.9.0mydirjava.desktopjdeps -s module-info.class
module-info.class - java.base
module-info.class - java.datatransfer
module-info.class - java.desktop
Mit dem Werkzeug jlink können JRE- und Appli-
kations-Images generiert werden, beispielsweise ein
JRE-Image, die nur die tatsächlich benötigten Module
enthalten (Abb. 2 und JEP 275 [6]). Außerdem könnte
jlink einige verborgene Verzahnungen für den eigenen
Image-Erzeugungsprozess beisteuern. Dies kann zur
individuellen Anpassung von Images vorteilhaft sein,
beispielsweise könnte die Funktionalität „removal of
executables“ für die jlink-Verarbeitung hinzugefügt
werden. Der neue jlink-Prozess wird zur Erzeugung
einer paketierten JRE verwendet, sobald die JDK-
9-JMOD-Dateien für den Java-Packager verfügbar
sind. Das jlink-Werkzeug enthält einen Plug-in- und
Erweiterungsmechanismus. Über solch einen integrier-
ten Mechanismus der jlink-Prozessausgabe wird ein
korrektes und plattformspezifisches Layout vom Appli-
kations-Image erzeugt. Dabei tritt der positive Neben-
effekt auf, dass die Applikations-Image-Generierung
vom javapackager-Prozess unabhängig ist. Mit Jigsaw
wird die Notation module path zusätzlich zum Class-
path eingeführt. Neue Optionen und Konfigurationen
werden zum Packer-API hinzugefügt, ein Ant-Plug-in
und ein Command-Line-Interface (CLI), damit der Be-
nutzer Module und Modulpfade zusätzlich zu jars und
dem Klassenpfad spezifizieren kann.
Im Dokument „Project Jigsaw: Module System Quick-
Start Guide“ [10] wird beispielhaft gezeigt, wie jlink
verwendet wird. Dazu werden folgende Dateien unter
C:src angelegt, im Verzeichnis C:mods dazu jeweils
die Klassendateien module-info.class und main. class
erzeugt und ausgeführt. Im Verzeichnis C:mlib wird
beispielhaft die jar-Datei erzeugt und dazu der Modul-
Descriptor gezeigt.
C:srccom.greetingsmodule-info.java
module com.greetings { }
C:srccom.greetingscomgreetingsMain.java
package com.greetings;
public class Main {
public static void main(String[] args) {
System.out.println(Greetings!);
}
}
C:javac -d mods/com.greetings src/com.greetings/module-info.java src/
com.greetings/com/greetings/Main.java
C:java -modulepath mods -m com.greetings/com.greetings.Main
Greetings!
C:jar --create --file=mlib/com.greetings.jar --main-class=com.greetings.
Main -C mods/com.greetings .
C:mlibjava -jar com.greetings.jar
Greetings!
C:mlibjar --print-module-descriptor --file=com.greetings.jar
Name: com.greetings
Requires: java.base [ MANDATED ]
Main class: com.greetings.Main
Conceals: com.greetings
Das Werkzeug jlink bekommt über --modulpath die
JDK-Module zugeführt, mit -addmods die eigenen Mo-
dule und die Struktur wird über -output in ein frei wähl-
bares Verzeichnis geschrieben. Das erzeugte Verzeichnis
greet­ings­app enthält die Unterverzeichnisse bin, conf, lib
und die Datei release Aus dem Modulpfad C:projects
jdk1.9.0jmods wurden die Module eingefügt und mit
-add­mods beispielhaft die Anwendungsdatei com.greet­
ings hinzugefügt (Kasten: „Datei ‚release’“).
jlink options --modulepath modulepath --output path
C:jlink --modulepath C:projectsjdk1.9.0jmods;mlib --addmods
com.greetings --output greetingsapp
Abb. 2: Mit dem Werkzeug jlink können JRE- und Applikations-Images generiert
werden, die nur die tatsächlich benötigten Module enthalten

9. Anzeige

10. javamagazin 1|2016
Java Core Jigsaw
32 www.JAXenter.de
C:greetingsappdir
Verzeichnis bin
Verzeichnis conf
Verzeichnis lib
Datei release
Fazit und Ausblick
Die Modularisierung der Java-SE-Plattform im JDK 9
bringt viele Vorteile. Wohlgemerkt sind auch einige grö-
ßere Änderungen damit verbunden. Existierender An-
wendungscode, der nur offizielle Java-SE-Plattform-APIs
mit den unterstützten JDK-spezifischen APIs verwendet,
soll auch weiterhin ohne Änderungen ablauffähig sein.
Nach wie vor ist die Abwärtskompatibilität für voran-
gegangene Hauptversionen mit Java SE gegeben, und
das gilt auch für das künftige JDK-9-Release mit Jigsaw.
Dennoch ist es wahrscheinlich, dass der Code unverträg-
lich sein kann, wenn weiterhin veraltete Funktionalität
oder JDK-interne APIs verwendet werden. Dafür können
sich die Entwickler frühzeitig damit vertraut machen, wie
existierende Bibliotheken und Anwendungen auf JDK 9
anzupassen sind, wie sie modularisiert werden, welche
Designfragen zu klären sind und wie man vorhandenen
Anwendungscode trotzdem mit JDK 9 zum Laufen be-
kommt, auch wenn man ihn nicht verändern kann.
Es ist ebenfalls notwendig zu untersuchen, wie das
neue modulare JDK auf die Java-UI-Client-Anwendun-
gen wie JavaFX reagiert. Die Verträglichkeit von Ja-
vaFX mit der Version „JDK 9 EA Jigsaw Build 83“ ist
gegeben, sodass existierende JavaFX-Anwendungen mit
kleineren Anpassungen auch mit dem künftigen JDK 9
arbeiten können.
Der Umgang mit dem künftigen JDK 9 erfordert
Kenntnis darüber, wie die Modulerstellung gemacht
wird, wie die Module kompiliert werden und viele
notwendige Testläufe, damit es zu einer reibungslosen
Inbetriebnahme von JDK-9-Anwendungen kommt.
Jigsaw trennt die APIs und die Implementierung von
Java-Komponenten und bietet mit diesem Modularisie-
rungsmodell eine bessere Unterstützung für große Java-
Projekte an. Dabei muss auch die Einbeziehung von
Java SE 9 mit automatisierten Build-Werkzeugen wie
Gradle betrachtet werden. Gradle Inc. ist am Jigsaw JSR
beteiligt und arbeitet an einem Gradle-Modell, um ein
bestmögliches Jigsaw-kompatibles Komponentenmo-
dell für JDK 9 anzubieten, wie es bereits für Java SE 7
und Java SE 8 existiert.
Mit dem JDK 9 verschmelzen die bisherige Java ME
mit der Java SE, sodass es dann nur noch die Java SE
gibt. Die notwendigen Funktionsmerkmale können mit-
hilfe von Jigsaw und seinen Werkzeuge individuell zu-
sammengestellt und durch die passenden Images auch
für kleinere Geräte maßgeschneidert erstellt werden.
Der vorgeschlagene Zeitplan sieht vor, dass der Feature-
Complete-Status am 10. Dezember 2015 erreicht wird.
Der finale Release-Candidate-Status ist am 21. Juli 2016
terminiert, und die geplante JDK-9-Release-Freigabe
soll am 22. September 2016 stattfinden. Passend zur
nächsten JavaOne 2016.
Wolfgang Weigend arbeitet als Sen. Leitender Systemberater bei
der Oracle Deutschland B.V. Co. KG. Er beschäftigt sich mit Ja-
va-Technologie und Architektur für unternehmensweite Anwen-
dungsentwicklung.
Datei „release“
#Wed Nov 04 01:04:55 CET 2015
OS_VERSION=5.1
JAVA_VERSION=1.9.0
OS_NAME=Windows
SOURCE= .:d555d542bf37 bdb:8ff6e91a0455
closed:afcd0cf7a01d corba:173fb1e5c13a
deploy:b900de8ea852 hotspot:00ba345866f4
hotspot/make/closed:5d3685711211 hot-
spot/src/closed:882ef256dd2b hotspot/test/
closed:029f0900e2ef install:4a2b8a2fe6f3
jaxp:722eca4b78a2 jaxws:49c4220a2a43
jdk:deb77851e5fd jdk/make/closed:06663e736525
jdk/src/closed:b46ce6e7b2bd jdk/test/
closed:e529d90cdb63 langtools:b40af8decd0b
nashorn:f9134ad4d147 pubs:3f64773e6db7
sponsors:12439cc89bb0
OS_ARCH=i586
MODULES=jdk.charsets,java.rmi,java.security.sasl,java.
datatransfer,java.prefs,jdk.localedata,jdk.crypto.ec,jdk.
naming.rmi,java.smartcardio,jdk.accessibility,jdk.security.
auth,com.greetings,java.xml.crypto,jdk.management,jdk.
management.cmm,jdk.naming.dns,java.base,java.
logging,java.desktop,java.naming,jdk.security.jgss,java.
transaction,java.xml,java.corba,java.scripting,jdk.
deploy,jdk.zipfs,jdk.scripting.nashorn,jdk.crypto.pkcs11,jdk.
crypto.mscapi,java.management,java.security.jgss
Links Literatur
[1] JEP 200: http://bit.ly/1MMwb0V
[2] JEP 201: http://bit.ly/1B9YkFU
[3] JEP 220: http://bit.ly/1XUfHWq
[4] JSR 376: http://bit.ly/1keFVVp
[5] JEP 261: http://bit.ly/1QiLtKo
[6] „The State of the Module System – Initial Edition“: http://bit.ly/1NwxeB0
[7] Downloadrelease „JDK 9 Early Access with Project Jigsaw, build b83“:
http://bit.ly/1MfUWwV
[8] zip-Datei-Release: „JDK 9 Early Access with Project Jigsaw, build b83“:
http://bit.ly/1OsNjsX
[9] JEP 275: http://bit.ly/1LUAL9V
[10] „Project Jigsaw: Module System Quick-Start Guide“: http://bit.
ly/1RAWZiS

11. www.entwickler.de
Java-Magazin-Abonnement abschließen auf www.entwickler.de
Jetzt abonnieren und
3 TOP-VORTEILE sichern!
Alle Printausgaben
frei Haus erhalten1
Im entwickler.kiosk
immer und überall
online lesen – am
Desktop und mobil
2
Mit vergünstigtem
Upgrade auf das
gesamte Angebot
im entwickler.kiosk
zugreifen
3