23. – 24. Februar 2016Courtyard 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:
NIchT veRPasseN!FRÜHBUCHERPREISE BIS 28. JANUAR SICHERN!
Java Magazin 1.2016
Android
Jigsaw
Vert.x M
icroservices Frege
JavaFX Java-/SAP-Integration
HTTP/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 aufspaltenBei 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.
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 ModuleDie 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 umstrukturierenDurch 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:
•$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 kompilierenDas 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 aufhebenDie bisherige Trennung von JRE und JDK ist historisch bedingt eine Konse-quenz aus der späten Implementierungsentscheidung bei der Entwicklung vom
florafeher
Schreibmaschinentext
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 BereicheDer 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ändlichDie 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 -WerkzeugeDas 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:\projects\jdk1.9.0>java -versionjava 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.0\lib\mo-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)\Java\jdk1.9.0\lib\modules die Modul-Images appmodules.jimage, bootmodules.jimage und extmodules.jimage enthalten. Beim JDK 9 EA Jigsaw b83 ist im Verzeichnis C:\pro-jects\jdk1.9.0\lib\modules nur das Modul-Image boot-modules.jimage enthalten. Über das Werkzeug jimage werden die Klassendateien vom bootmodules.jimage im Pfad C:\projects\jdk1.9.0\lib\modules> 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:\projects\jdk1.9.0\mydir 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:
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:\src\com.greetings\module-info.java
module com.greetings { }
C:\src\com.greetings\com\greetings\Main.java
package com.greetings; public class Main { public static void main(String[] args) { System.out.println("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.0\jmods wurden die Module eingefügt und mit -add mods beispielhaft die Anwendungsdatei com.greet-ings hinzugefügt (Kasten: „Datei ‚release’“).
Abb. 2: Mit dem Werkzeug jlink können JRE- und Applikations-Images generiert werden, die nur die tatsächlich benötigten Module enthalten
Wir suchen ab sofortWeb-Softwareentwickler (m/w) zur Verstärkung unseres Application-Development-Teams in Karlsruhe, Pforzheim, Köln, München oder Hamburg.
Interesse an Material Design, Web Components und anderen Web-Technologien? Dann haben wir das passende Angebot: Wir suchen Web-Softwareentwickler, die virtuos mit JavaScript, HTML5 oder Ruby on Rails umgehen können und bei einem innovativen Arbeitgeber in spannenden Projekten das Gesicht des Internets mitprägen möchten.
Fazit und AusblickDie 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.
