SlideShare ist ein Scribd-Unternehmen logo
1 von 11
Downloaden Sie, um offline zu lesen
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
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
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.
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
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
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
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.
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
Anzeige
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
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

Weitere ähnliche Inhalte

Andere mochten auch

Metadatenbasierte Validierung
Metadatenbasierte ValidierungMetadatenbasierte Validierung
Metadatenbasierte Validierungos890
 
TOC in der Beratungspraxis 21.08.15
TOC in der Beratungspraxis 21.08.15TOC in der Beratungspraxis 21.08.15
TOC in der Beratungspraxis 21.08.15ICV
 
Using Theory of Constraints in Services
Using Theory of Constraints in ServicesUsing Theory of Constraints in Services
Using Theory of Constraints in ServicesBusiness901
 
Goldratt's Theory of Constraints - An Introduction
Goldratt's Theory of Constraints - An IntroductionGoldratt's Theory of Constraints - An Introduction
Goldratt's Theory of Constraints - An IntroductionFred Wiersma
 
Theory of constraints
Theory of constraintsTheory of constraints
Theory of constraintsMOHD ARISH
 
Durchsatzrechnung vs. Kostenrechnung (erweiterte Version)
Durchsatzrechnung vs. Kostenrechnung (erweiterte Version)Durchsatzrechnung vs. Kostenrechnung (erweiterte Version)
Durchsatzrechnung vs. Kostenrechnung (erweiterte Version)Marco Geuer
 
Daten- und Informationsqualitätsmanagement als integraler Baustein von Manage...
Daten- und Informationsqualitätsmanagement als integraler Baustein von Manage...Daten- und Informationsqualitätsmanagement als integraler Baustein von Manage...
Daten- und Informationsqualitätsmanagement als integraler Baustein von Manage...Marco Geuer
 
Oracle Old Features DOAG 2011
Oracle Old Features DOAG 2011Oracle Old Features DOAG 2011
Oracle Old Features DOAG 2011Uwe Küchler
 
Agile Skalierung ohne Blaupause (PMI Agile Hamburg, 19.05.2014)
Agile Skalierung ohne Blaupause (PMI Agile Hamburg, 19.05.2014)Agile Skalierung ohne Blaupause (PMI Agile Hamburg, 19.05.2014)
Agile Skalierung ohne Blaupause (PMI Agile Hamburg, 19.05.2014)Stefan ROOCK
 
Constraints Management
Constraints ManagementConstraints Management
Constraints ManagementWandelBarCamp
 
Usability and HCI
Usability and HCIUsability and HCI
Usability and HCINina Rebele
 
Was ist dran an Kanban?
Was ist dran an Kanban?Was ist dran an Kanban?
Was ist dran an Kanban?Bernd Schiffer
 
Scrum in der Medizintechnik - dürfen wir das überhaupt? (Consanis)
Scrum in der Medizintechnik - dürfen wir das überhaupt? (Consanis)Scrum in der Medizintechnik - dürfen wir das überhaupt? (Consanis)
Scrum in der Medizintechnik - dürfen wir das überhaupt? (Consanis)Frank Lange
 
Agile Methoden und die Theory of Constraints
Agile Methoden und die Theory of ConstraintsAgile Methoden und die Theory of Constraints
Agile Methoden und die Theory of ConstraintsFrank Lange
 
Grounded Theory
Grounded TheoryGrounded Theory
Grounded Theorywruge
 
Agil skalieren ohne Blaupause (JAX 2014)
Agil skalieren ohne Blaupause (JAX 2014)Agil skalieren ohne Blaupause (JAX 2014)
Agil skalieren ohne Blaupause (JAX 2014)Dr. Arne Roock
 

Andere mochten auch (17)

Metadatenbasierte Validierung
Metadatenbasierte ValidierungMetadatenbasierte Validierung
Metadatenbasierte Validierung
 
TOC in der Beratungspraxis 21.08.15
TOC in der Beratungspraxis 21.08.15TOC in der Beratungspraxis 21.08.15
TOC in der Beratungspraxis 21.08.15
 
Using Theory of Constraints in Services
Using Theory of Constraints in ServicesUsing Theory of Constraints in Services
Using Theory of Constraints in Services
 
Goldratt's Theory of Constraints - An Introduction
Goldratt's Theory of Constraints - An IntroductionGoldratt's Theory of Constraints - An Introduction
Goldratt's Theory of Constraints - An Introduction
 
Theory of constraints
Theory of constraintsTheory of constraints
Theory of constraints
 
Durchsatzrechnung vs. Kostenrechnung (erweiterte Version)
Durchsatzrechnung vs. Kostenrechnung (erweiterte Version)Durchsatzrechnung vs. Kostenrechnung (erweiterte Version)
Durchsatzrechnung vs. Kostenrechnung (erweiterte Version)
 
Daten- und Informationsqualitätsmanagement als integraler Baustein von Manage...
Daten- und Informationsqualitätsmanagement als integraler Baustein von Manage...Daten- und Informationsqualitätsmanagement als integraler Baustein von Manage...
Daten- und Informationsqualitätsmanagement als integraler Baustein von Manage...
 
Oracle Old Features DOAG 2011
Oracle Old Features DOAG 2011Oracle Old Features DOAG 2011
Oracle Old Features DOAG 2011
 
Agile Skalierung ohne Blaupause (PMI Agile Hamburg, 19.05.2014)
Agile Skalierung ohne Blaupause (PMI Agile Hamburg, 19.05.2014)Agile Skalierung ohne Blaupause (PMI Agile Hamburg, 19.05.2014)
Agile Skalierung ohne Blaupause (PMI Agile Hamburg, 19.05.2014)
 
Constraints Management
Constraints ManagementConstraints Management
Constraints Management
 
Usability and HCI
Usability and HCIUsability and HCI
Usability and HCI
 
Was ist dran an Kanban?
Was ist dran an Kanban?Was ist dran an Kanban?
Was ist dran an Kanban?
 
b!g Scrumday OOP2011 Scrum-Metriken
b!g  Scrumday OOP2011 Scrum-Metrikenb!g  Scrumday OOP2011 Scrum-Metriken
b!g Scrumday OOP2011 Scrum-Metriken
 
Scrum in der Medizintechnik - dürfen wir das überhaupt? (Consanis)
Scrum in der Medizintechnik - dürfen wir das überhaupt? (Consanis)Scrum in der Medizintechnik - dürfen wir das überhaupt? (Consanis)
Scrum in der Medizintechnik - dürfen wir das überhaupt? (Consanis)
 
Agile Methoden und die Theory of Constraints
Agile Methoden und die Theory of ConstraintsAgile Methoden und die Theory of Constraints
Agile Methoden und die Theory of Constraints
 
Grounded Theory
Grounded TheoryGrounded Theory
Grounded Theory
 
Agil skalieren ohne Blaupause (JAX 2014)
Agil skalieren ohne Blaupause (JAX 2014)Agil skalieren ohne Blaupause (JAX 2014)
Agil skalieren ohne Blaupause (JAX 2014)
 

Ähnlich wie Javamagazin 1.2016 jdk9_ea_b83_jigsaw

EnterJS 2015 - JavaScript von Morgen schon heute
EnterJS 2015 - JavaScript von Morgen schon heuteEnterJS 2015 - JavaScript von Morgen schon heute
EnterJS 2015 - JavaScript von Morgen schon heutePhilipp Burgmer
 
Using openArchitectureWare 4.0 in domain "registration"
Using openArchitectureWare 4.0 in domain "registration"Using openArchitectureWare 4.0 in domain "registration"
Using openArchitectureWare 4.0 in domain "registration"joergreichert
 
Morphia, Spring Data & Co
Morphia, Spring Data & CoMorphia, Spring Data & Co
Morphia, Spring Data & CoTobias Trelle
 
Introduction to JEE
Introduction to JEEIntroduction to JEE
Introduction to JEEguestc44b7b
 
iJUG Java Aktuell [Februar 2015] Lukas Eder - jOOQ - ein alternativer Weg mit...
iJUG Java Aktuell [Februar 2015] Lukas Eder - jOOQ - ein alternativer Weg mit...iJUG Java Aktuell [Februar 2015] Lukas Eder - jOOQ - ein alternativer Weg mit...
iJUG Java Aktuell [Februar 2015] Lukas Eder - jOOQ - ein alternativer Weg mit...Lukas Eder
 
Jm 10.13 weigend_lagergren_nashorn
Jm 10.13 weigend_lagergren_nashornJm 10.13 weigend_lagergren_nashorn
Jm 10.13 weigend_lagergren_nashornWolfgang Weigend
 
Java magazin9 2012_wls 12c_das_dutzend_ist_voll
Java magazin9 2012_wls 12c_das_dutzend_ist_vollJava magazin9 2012_wls 12c_das_dutzend_ist_voll
Java magazin9 2012_wls 12c_das_dutzend_ist_vollWolfgang Weigend
 
Gradle - Beginner's Workshop (german)
Gradle - Beginner's Workshop (german)Gradle - Beginner's Workshop (german)
Gradle - Beginner's Workshop (german)Joachim Baumann
 
JM 01/09 - OSGi in kleinen Dosen 2
JM 01/09 - OSGi in kleinen Dosen 2JM 01/09 - OSGi in kleinen Dosen 2
JM 01/09 - OSGi in kleinen Dosen 2Heiko Seeberger
 
JUG MZ OSGi Lightning Talk
JUG MZ OSGi Lightning TalkJUG MZ OSGi Lightning Talk
JUG MZ OSGi Lightning TalkThilo Käsemann
 
Server Revolutions- Der Spring Source DM Server
Server Revolutions- Der Spring Source DM ServerServer Revolutions- Der Spring Source DM Server
Server Revolutions- Der Spring Source DM ServerSandro Sonntag
 
The JDK 8 end of public updates and the Java SE subscription
The JDK 8 end of public updates and the Java SE subscription The JDK 8 end of public updates and the Java SE subscription
The JDK 8 end of public updates and the Java SE subscription Wolfgang Weigend
 
Apps for the Enterprise - Ein einheitliches Modulsystem für verteilte Unterne...
Apps for the Enterprise - Ein einheitliches Modulsystem für verteilte Unterne...Apps for the Enterprise - Ein einheitliches Modulsystem für verteilte Unterne...
Apps for the Enterprise - Ein einheitliches Modulsystem für verteilte Unterne...Andreas Weidinger
 
Scala - OSGi Bundles from Outer (Java) Space
Scala - OSGi Bundles from Outer (Java) SpaceScala - OSGi Bundles from Outer (Java) Space
Scala - OSGi Bundles from Outer (Java) SpaceOliver Braun
 
Von Maven zu Gradle in 45 Minuten
Von Maven zu Gradle in 45 MinutenVon Maven zu Gradle in 45 Minuten
Von Maven zu Gradle in 45 MinutenQAware GmbH
 

Ähnlich wie Javamagazin 1.2016 jdk9_ea_b83_jigsaw (20)

EnterJS 2015 - JavaScript von Morgen schon heute
EnterJS 2015 - JavaScript von Morgen schon heuteEnterJS 2015 - JavaScript von Morgen schon heute
EnterJS 2015 - JavaScript von Morgen schon heute
 
Using openArchitectureWare 4.0 in domain "registration"
Using openArchitectureWare 4.0 in domain "registration"Using openArchitectureWare 4.0 in domain "registration"
Using openArchitectureWare 4.0 in domain "registration"
 
Morphia, Spring Data & Co
Morphia, Spring Data & CoMorphia, Spring Data & Co
Morphia, Spring Data & Co
 
Introduction to JEE
Introduction to JEEIntroduction to JEE
Introduction to JEE
 
iJUG Java Aktuell [Februar 2015] Lukas Eder - jOOQ - ein alternativer Weg mit...
iJUG Java Aktuell [Februar 2015] Lukas Eder - jOOQ - ein alternativer Weg mit...iJUG Java Aktuell [Februar 2015] Lukas Eder - jOOQ - ein alternativer Weg mit...
iJUG Java Aktuell [Februar 2015] Lukas Eder - jOOQ - ein alternativer Weg mit...
 
Jm 10.13 weigend_lagergren_nashorn
Jm 10.13 weigend_lagergren_nashornJm 10.13 weigend_lagergren_nashorn
Jm 10.13 weigend_lagergren_nashorn
 
Java magazin9 2012_wls 12c_das_dutzend_ist_voll
Java magazin9 2012_wls 12c_das_dutzend_ist_vollJava magazin9 2012_wls 12c_das_dutzend_ist_voll
Java magazin9 2012_wls 12c_das_dutzend_ist_voll
 
Gradle - Beginner's Workshop (german)
Gradle - Beginner's Workshop (german)Gradle - Beginner's Workshop (german)
Gradle - Beginner's Workshop (german)
 
CDI
CDICDI
CDI
 
Elsholz stoll js_03_10
Elsholz stoll js_03_10Elsholz stoll js_03_10
Elsholz stoll js_03_10
 
Die Java Plattform Strategie
Die Java Plattform StrategieDie Java Plattform Strategie
Die Java Plattform Strategie
 
JM 01/09 - OSGi in kleinen Dosen 2
JM 01/09 - OSGi in kleinen Dosen 2JM 01/09 - OSGi in kleinen Dosen 2
JM 01/09 - OSGi in kleinen Dosen 2
 
JUG MZ OSGi Lightning Talk
JUG MZ OSGi Lightning TalkJUG MZ OSGi Lightning Talk
JUG MZ OSGi Lightning Talk
 
Server Revolutions- Der Spring Source DM Server
Server Revolutions- Der Spring Source DM ServerServer Revolutions- Der Spring Source DM Server
Server Revolutions- Der Spring Source DM Server
 
The JDK 8 end of public updates and the Java SE subscription
The JDK 8 end of public updates and the Java SE subscription The JDK 8 end of public updates and the Java SE subscription
The JDK 8 end of public updates and the Java SE subscription
 
JavaFX goes open source
JavaFX goes open sourceJavaFX goes open source
JavaFX goes open source
 
Apps for the Enterprise - Ein einheitliches Modulsystem für verteilte Unterne...
Apps for the Enterprise - Ein einheitliches Modulsystem für verteilte Unterne...Apps for the Enterprise - Ein einheitliches Modulsystem für verteilte Unterne...
Apps for the Enterprise - Ein einheitliches Modulsystem für verteilte Unterne...
 
OC|Webcast "Java heute" vom 24.08.2021
OC|Webcast "Java heute" vom 24.08.2021OC|Webcast "Java heute" vom 24.08.2021
OC|Webcast "Java heute" vom 24.08.2021
 
Scala - OSGi Bundles from Outer (Java) Space
Scala - OSGi Bundles from Outer (Java) SpaceScala - OSGi Bundles from Outer (Java) Space
Scala - OSGi Bundles from Outer (Java) Space
 
Von Maven zu Gradle in 45 Minuten
Von Maven zu Gradle in 45 MinutenVon Maven zu Gradle in 45 Minuten
Von Maven zu Gradle in 45 Minuten
 

Mehr von Wolfgang Weigend

It's a JDK- Jungle Out There – JDK 15 and OpenJDK 15
It's a JDK- Jungle Out There – JDK 15 and OpenJDK 15It's a JDK- Jungle Out There – JDK 15 and OpenJDK 15
It's a JDK- Jungle Out There – JDK 15 and OpenJDK 15Wolfgang Weigend
 
It's a jdk jungle out there - JDK 11 and OpenJDK 11
It's a jdk jungle out there - JDK 11 and OpenJDK 11It's a jdk jungle out there - JDK 11 and OpenJDK 11
It's a jdk jungle out there - JDK 11 and OpenJDK 11Wolfgang Weigend
 
Microservices and Container
Microservices and ContainerMicroservices and Container
Microservices and ContainerWolfgang Weigend
 
JDK 9 Java Platform Module System
JDK 9 Java Platform Module SystemJDK 9 Java Platform Module System
JDK 9 Java Platform Module SystemWolfgang Weigend
 
fn project serverless computing
fn project serverless computingfn project serverless computing
fn project serverless computingWolfgang Weigend
 
Development with JavaFX 9 in JDK 9.0.1
Development with JavaFX 9 in JDK 9.0.1Development with JavaFX 9 in JDK 9.0.1
Development with JavaFX 9 in JDK 9.0.1Wolfgang Weigend
 
Java Flight Recorder Javamagazin May 2017
Java Flight Recorder Javamagazin May 2017Java Flight Recorder Javamagazin May 2017
Java Flight Recorder Javamagazin May 2017Wolfgang Weigend
 
Automated testing of JavaFX GUI components
Automated testing of JavaFX GUI componentsAutomated testing of JavaFX GUI components
Automated testing of JavaFX GUI componentsWolfgang Weigend
 
Java mission control and java flight recorder
Java mission control and java flight recorderJava mission control and java flight recorder
Java mission control and java flight recorderWolfgang Weigend
 
Automated testing of JavaFX UI components
Automated testing of JavaFX UI componentsAutomated testing of JavaFX UI components
Automated testing of JavaFX UI componentsWolfgang Weigend
 
JDK 8 and JDK 8 Updates in OpenJDK
JDK 8 and JDK 8 Updates in OpenJDKJDK 8 and JDK 8 Updates in OpenJDK
JDK 8 and JDK 8 Updates in OpenJDKWolfgang Weigend
 

Mehr von Wolfgang Weigend (13)

It's a JDK- Jungle Out There – JDK 15 and OpenJDK 15
It's a JDK- Jungle Out There – JDK 15 and OpenJDK 15It's a JDK- Jungle Out There – JDK 15 and OpenJDK 15
It's a JDK- Jungle Out There – JDK 15 and OpenJDK 15
 
It's a jdk jungle out there - JDK 11 and OpenJDK 11
It's a jdk jungle out there - JDK 11 and OpenJDK 11It's a jdk jungle out there - JDK 11 and OpenJDK 11
It's a jdk jungle out there - JDK 11 and OpenJDK 11
 
JDK versions and OpenJDK
JDK versions and OpenJDKJDK versions and OpenJDK
JDK versions and OpenJDK
 
JDK 10 Java Module System
JDK 10 Java Module SystemJDK 10 Java Module System
JDK 10 Java Module System
 
Microservices and Container
Microservices and ContainerMicroservices and Container
Microservices and Container
 
JDK 9 Java Platform Module System
JDK 9 Java Platform Module SystemJDK 9 Java Platform Module System
JDK 9 Java Platform Module System
 
fn project serverless computing
fn project serverless computingfn project serverless computing
fn project serverless computing
 
Development with JavaFX 9 in JDK 9.0.1
Development with JavaFX 9 in JDK 9.0.1Development with JavaFX 9 in JDK 9.0.1
Development with JavaFX 9 in JDK 9.0.1
 
Java Flight Recorder Javamagazin May 2017
Java Flight Recorder Javamagazin May 2017Java Flight Recorder Javamagazin May 2017
Java Flight Recorder Javamagazin May 2017
 
Automated testing of JavaFX GUI components
Automated testing of JavaFX GUI componentsAutomated testing of JavaFX GUI components
Automated testing of JavaFX GUI components
 
Java mission control and java flight recorder
Java mission control and java flight recorderJava mission control and java flight recorder
Java mission control and java flight recorder
 
Automated testing of JavaFX UI components
Automated testing of JavaFX UI componentsAutomated testing of JavaFX UI components
Automated testing of JavaFX UI components
 
JDK 8 and JDK 8 Updates in OpenJDK
JDK 8 and JDK 8 Updates in OpenJDKJDK 8 and JDK 8 Updates in OpenJDK
JDK 8 and JDK 8 Updates in OpenJDK
 

Javamagazin 1.2016 jdk9_ea_b83_jigsaw

  • 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
  • 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