JDK 9 Java Platform Module System

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
Title Slide with
Java FY15 Theme
Subtitle
Presenter’s Name
Presenter’s Title
Organization, Division or Business Unit
Month 00, 2014
Note: The speaker notes for this slide
include detailed instructions on how to reuse
this Title Slide in another presentation.
Tip! Remember to remove this text box.
Copyright © 2014, Oracle and/or its affiliates. All rights reserved.
JDK 9
Java Platform Module System
Wolfgang Weigend
Sen. Leitender Systemberater
Java Technology and Architecture

Safe Harbor Statement
The preceding is intended to outline our general product direction. It is intended for
information purposes only, and may not be incorporated into any contract. It is not a
commitment to deliver any material, code, or functionality, and should not be relied upon
in making purchasing decisions. The development, release, and timing of any features or
functionality described for Oracle’s products remains at the sole discretion of Oracle.
2

23 Years of Java ..

Agenda
JDK 9 JEP’s and Versioning
Migration Guide
Modularity
Jigsaw and the Tools
Summary
1
2
3
4
4
5

JDK 9 – JEP’s and Versioning

JDK 9 - JEP’s included
http://openjdk.java.net/projects/jdk9/
6
102: Process API Updates
110: HTTP 2 Client
143: Improve Contended Locking
158: Unified JVM Logging
165: Compiler Control
193: Variable Handles
197: Segmented Code Cache
199: Smart Java Compilation, Phase Two
200: The Modular JDK
201: Modular Source Code
211: Elide Deprecation Warnings on Import Statements
212: Resolve Lint and Doclint Warnings
213: Milling Project Coin
214: Remove GC Combinations Deprecated in JDK 8
215: Tiered Attribution for javac
216: Process Import Statements Correctly
217: Annotations Pipeline 2.0
219: Datagram Transport Layer Security (DTLS)
220: Modular Run-Time Images
221: Simplified Doclet API
222: jshell: The Java Shell (Read-Eval-Print Loop)
223: New Version-String Scheme
224: HTML5 Javadoc
225: Javadoc Search
226: UTF-8 Property Files
227: Unicode 7.0
228: Add More Diagnostic Commands
229: Create PKCS12 Keystores by Default
231: Remove Launch-Time JRE Version Selection

JDK 9 - G1 Garbage Collector as the default
• GC pause-times have the largest impact on application
performance, predictability and responsiveness
• One large contiguous heap space divided into many fixed
size regions
– Size can be 1 MB – 32 MB
– Only GC that can scale up to multi-TB heap
● Each region can be assigned a unique
eviction/compaction policy (Eden region, Survivor region,
Humongous or Old region)
● Per region scalable collection process
● Allow optimized memory mapping between the OS and
the JVM
E
S
OO
O
O
O
O
O O
O
O
OO
O
O HO
S
SS
E
E E
E
EE
H
O
H
O
E
S
Eden regions
Survivor regions
Old generation regions
H Humongous regions
Available / Unused regions

JEP 222: jshell Architecture (2)
Useful for prototyping and testing Java code snippets

JEP 223: New Version-String Scheme (1)
Revise the JDK's version-string scheme: Project Verona
10
• It's long past time for a simpler, more intuitive versioning scheme.
• A version number is a non-empty sequence of non-negative integer
numerals, without leading zeroes, separated by period characters
– [1-9][0-9]*(.(0|[1-9][0-9]*))*
• $MAJOR.$MINOR.$SECURITY
• A version string consists of a version number $VNUM, as described above,
optionally followed by pre-release and build information
• This proposal drops the initial 1 element from JDK version numbers.
– First release of JDK 9 will have the version number 9.0.0 rather than 1.9.0.0.

New version-string format
11
Old New
Release Type long short long short
------------ -------------------- ---------------------
Early Access 1.9.0-ea-b19 9-ea 9-ea+19 9-ea
Major 1.9.0-b100 9 9+100 9
Security #1 1.9.0_5-b20 9u5 9.0.1+20 9.0.1
Security #2 1.9.0_11-b12 9u11 9.0.2+12 9.0.2
Minor #1 1.9.0_20-b62 9u20 9.1.2+62 9.1.2
Security #3 1.9.0_25-b15 9u25 9.1.3+15 9.1.3
Security #4 1.9.0_31-b08 9u31 9.1.4+8 9.1.4
Minor #2 1.9.0_40-b45 9u40 9.2.4+45 9.2.4

A simple JDK-specific Java API to parse, validate, and compare version strings
12
package jdk;
import java.util.Optional;
public class Version
implements Comparable<Version>
{
public static Version parse(String);
public static Version current();
public int major();
public int minor();
public int security();
public List<Integer> version();
public Optional<String> pre();
public Optional<Integer> build();
public Optional<String> optional();
public int compareTo(Version o);
public int compareToIgnoreOpt(Version o);
public boolean equals(Object o);
public boolean equalsIgnoreOpt(Object o);
public String toString();
public int hashCode();
}
Release Type Versions
---------------- -----------
Major (GA) jdk-9+100
Minor #1 (GA) jdk-9.1.2+27
Security #1 (GA) jdk-9.0.1+3

Rules for Java CPU’s
− Main release for security vulnerabilities
− Covers all JDK families (9, 8, 7, 6)
− CPU release triggers Auto-update
− Dates published 12 months in advance
− Security Alerts are released as necessary
− Based off the previous (non-CPU) release
− Released simultaneously on java.com and OTN
JDK 9.0.4 - Security Baselines
JRE Family Version
JRE Security Baseline
(Full Version String)
9 9.0.4+11
8 1.8.0_161-b12
7 1.7.0_171-b11
6 1.6.0_181-b10
JDK Version numbers and Java Critical Patch Updates

A version number, $VNUM, is a sequence of numerals of arbitrary length, separated by period characters.
The first four numerals are interpreted as follows: $FEATURE.$INTERIM.$UPDATE.$EMERG
$FEATURE -- The feature-release counter, incremented every six months regardless of release content.
Thus the March 2018 release is 10, the September 2018 release is 11, and so forth. Features may be added
in a feature release; they may also be removed, if advance notice was given at least one feature release
ahead of time. Incompatible changes may be made when justified.
Formerly $MAJOR.
JDK Version numbers (1)

A version number, $VNUM, is a sequence of numerals of arbitrary length, separated by period characters. The first four
numerals are interpreted as follows: $FEATURE.$INTERIM.$UPDATE.$EMERG
$INTERIM -- The interim-release counter, incremented for non-feature releases that contain compatible bug fixes and
enhancements but no incompatible changes, no feature removals, and no changes to standard APIs. This counter is always
zero for the current six-month release model. We reserve it here to leave flexibility for the future, so that some future
release model could say that JDK $N.1 and JDK $N.2 are compatible upgrades of JDK $N. Leaving this counter at zero for
the current model has an additional benefit in that it increases the degree to which version numbers continue to reflect,
roughly, both compatibility and significance.
Formerly $MINOR.

$UPDATE -- The update-release counter, incremented every three months for compatible update releases
that fix security issues, regressions, and bugs in newer features. Thus the April 2018 release is 10.0.1, the
July release is 10.0.2, and so forth.
Formerly $SECURITY, but with a non-trivial incrementation rule.

$EMERG -- The emergency-release counter, incremented only when it's necessary to produce an
emergency release to fix an urgent security issue. Using an additional numeral for this purpose minimizes
the disruption to both developers and users of in-flight update releases.

A version number, $VNUM, is a sequence of numerals of arbitrary length, separated by period characters. The first
four numerals are interpreted as follows: $FEATURE.$INTERIM.$UPDATE.$EMERG
This is primarily a time-based scheme, since $FEATURE is incremented every six months regardless of release
content and, for each feature release, $UPDATE is incremented every three months. We do expect most feature
releases to contain at least one or two significant features, and never to ship interim releases under the new release
model, so in practice this scheme will often be very similar to a compatibility- or significance-oriented scheme like
that of JEP 223. JDK 10 is a feature release, JDK 10.0.1 and 10.0.2 are update releases with compatible bug fixes,
and there is no interim JDK 10.1 release since in this model the next opportunity to add features is JDK 11.

16th of January 2017
17th of April 2018
17th of July 2018
16th of October 2018
15th of January 2019
Scheduled CPU‘s
http://www.oracle.com/technetwork/topics/security/alerts-086861.html
Java Critical Patch Updates and upcoming

Java SE Public Updates
http://www.oracle.com/technetwork/java/eol-135779.html

Oracle Java SE Support Roadmap*
http://www.oracle.com/technetwork/java/eol-135779.html

Migration Guide

Migrating to Oracle JDK 9 - Migration Guide (1)
https://docs.oracle.com/javase/9/migrate/
23
• How to proceed as you migrate your existing Java application to JDK 9
• Every new Java SE release introduces some binary, source and behavioral incompatibilities with previous releases
• The modularization of the Java SE Platform brings many benefits but also many changes
• Code that uses only official Java SE Platform APIs and supported JDK-specific APIs should continue to work without change
• Code that uses certain features or JDK-internal APIs may not run or may give different results
• Prepare for Migration
• Get the JDK 9 Build
• Run Your Program Before Recompiling
• Update Third-Party Libraries
• Compile Your Application
• Run jdeps on Your Code

https://docs.oracle.com/javase/9/migrate/
24
• Beware of changes that you may encounter as you run your application
• Changes to the Installed JDK/JRE Image
• Removed APIs
• Deployment
• Changes to Garbage Collection
• Removed Tools
• Removed macOS-specific Features

Removed Tools
25
– JavaDB, which was a rebranding of Apache Derby, is not included in JDK 9
– JVM Tools Interface hprof agent library (libhprof.so) has been removed
• The hprof agent was written as demonstration code for the JVM Tool Interface and not intended to be a production tool. The useful features of the
hprof agent have been superseded by better tools in the JDK
– The jhat tool was an experimental, unsupported heap visualization tool added in JDK 6. Superior
heap visualizers and analyzers have been available for many years
– The launchers java-rmi.exe from Windows and java-rmi.cgi from Linux and Solaris have been
removed
– The IIOP transport support from the JMX RMI Connector along with its supporting classes have
been removed in JDK 9
– Windows 32 Client VM is dropped and only a server VM is offered in JDK 9
– Visual VM removed
• Visual VM is a tool that provides information about code running on a Java Virtual Machine. It was provided with JDK 6, JDK 7, and JDK 8
• Visual VM is not bundled with JDK 9. If you would like to use Visual VM with JDK 9, you can get it from the Visual VM open source project site

Modularity

• These are the final results of the Public Review Reconsideration Ballot for JSR #376.
• The EC has approved this ballot. The votes are below:
27
JSR 376: Java Platform Module System (1)
Public Review Reconsideration Ballot from 2017-06-13 to 2017-06-26
On 2017-06-13 IBM voted Yes with the following comment:
IBM supports the revised JPMS specification moving to Proposed
Final Draft, with credit due to Oracle as the specification leader
and those in the JSR 376 Expert Group who dedicated their time to
reaching this milestone.

Modular Development with JDK 9
28

Goals of the Java SE 9 Module System (1)
• Reliable configuration with better maintenance
– replace the brittle, error-prone class-path mechanism with a means for program components to declare
explicit dependences upon one another
– Each modul exists once
– Verification of all necessary modules exist at start time
• Strong encapsulation
– allow a component to declare which of its public types are accessible to other components, and which
are not. Prevents access to non-public classes and API’s
– module can declare an API to other modules
– packages not on the API are hidden
• Addressing these goals would enable further benefits:
– A scalable platform for deployment of small applications and tiny runtime
– Greater platform integrity and Improved performance
29

Non-Goals of the Java SE 9 Module System (2)
• The Java Platform Module System does not replace OSGi
• The Java Platform Module System does not support versioning of modules
30

• Provide a means for developers and libraries to define their own modules
• Reflection API‘s for module information
• Integration with developer tools (Maven, Gradle, IDE‘s)
• Integration with existing package managers (e.g., RPM)
• Dynamic configuration of module graph (e.g., for Java EE containers)
• Current documents, code, & builds
Requirements
The State of the Module System (design overview)
Initial draft JLS and JVMS changes
Draft API specification (diffs relative to JDK 9)
java.lang.Class
java.lang.ClassLoader
java.lang.reflect.Module
java.lang.module
Issue summary
RI prototype: Source, binary
31
JSR 376: Java Platform Module System (2)
An approachable yet scalable module system for the Java Platform

JSR 376 Java Platform Module System
JEP 200: The Modular JDK
JEP 201: Modular Source Code
JEP 220: Modular Run-Time Images
JEP 260: Encapsulate Most Internal APIs
JEP 261: Module System
JEP 282: jlink - The Java Linker
JDK 9 GA – JDK 9+181
JDK 9.0.4 Release is here: http://jdk.java.net/9/
Projekt Jigsaw
JDK Enhancement Proposal’s (JEP’s)
32

JEP 200: The Modular JDK (1)
• Make minimal assumptions about the module system that will be used to
implement that structure.
• Divide the JDK into a set of modules that can be combined at compile time,
build time, install time, or run time into a variety of configurations including,
but not limited to:
– Configurations corresponding to the full Java SE Platform, the full JRE, and the full JDK;
– Configurations roughly equivalent in content to each of the Compact Profiles defined
in Java SE 8; and
– Custom configurations which contain only a specified set of modules and the modules
transitively required by those modules.
33
Goal: Define a modular structure for the JDK

• can contain class files, resources, and related native and configuration files.
• has a name.
• can depend, by module name, upon one or more other modules.
• can export all of the public types in one or more of the API packages that it contains, making them
available to code in other modules depending on it
• can restrict, by module name, the set of modules to which the public types in one or more of its API
packages are exported. (sharing internal interface)
• can re-export all of the public types that are exported by one or more of the modules upon which it
depends. (support refactoring & aggregation)
A module is a set of packages with classes & interfaces
The module metadata is in module-info.class
34
Module System Assumptions: A module …

• Standard modules, whose specifications are governed by the JCP, must
have names starting with the string "java.".
• All other modules are merely part of the JDK, and must have names
starting with the string "jdk.".
• If a module exports a type that contains a public or protected member
that, in turn, refers to a type from some other module then the first
module must re-export the public types of the second. This ensures that
method-invocation chaining works in the obvious way.
• Additional principles in JEP 200 text to ensure that code which depends
only upon Java SE modules will depend only upon standard Java SE types.
35
Design Principles

36
Module Graph

Modules
• A module is a named, self-describing collection of code & data
– Code is organized as a set of packages containing types
• It declares which other modules it requires in order to be compiled and run
• It declares which of its packages it exports.
• Module system locates modules
– Ensures code in a module can only refer to types in modules upon which it depends
– The access-control mechanisms of the Java language and the Java virtual machine
prevent code from accessing types in packages that are not exported by their defining
modules.
37
A fundamental new kind of Java component

Module descriptors
• class files already have a precisely-defined and extensible format
• consider module-info.class file as module descriptor
– includes the compiled forms of source-level module declarations
– may include additional kinds of information recorded in class-file attributes
• inserted after the declaration is initially compiled.
• An IDE can insert class file attributes containing documentary information
– module version, title, description, and license.
• This information can be read at compile time and run time
– for use in documentation, diagnosis, and debugging
38
module-info.class advantages

Platform modules
• The only module known specifically to the module system is java.base.
– The base module is always present. Every other module depends implicitly upon the
base module, while the base module depends upon no other modules
• The base module defines and exports all of the platform’s core packages,
including the module system itself:
module java.base {
exports java.io;
exports java.lang;
exports java.lang.module;
... }
39
Modules all the way down to the base module: java.base

Module Paths
• module system can select a module to resolve a dependence
– built-in to the compile-time or run-time environment or
– a module defined in an artifact
• the module system locates artifacts on one or more module paths defined by the host system.
• A module path is a sequence of directories containing module artifacts
– searched, in order, for the first artifact that defines a suitable module.
• Module paths are materially different from class paths, and more robust:
– A class path is a means to locate individual types in all the artifacts on the path.
– A module path is a means to locate whole modules rather than individual types.
• If a particular dependence can not be fulfilled then resolution will fail with an error message
40
Where do modules fulfilling dependences come from?

Packages and Modules - Module Declarations
41
ModuleDirective:
requires {RequiresModifier} ModuleName ;
exports PackageName [to ModuleName {, ModuleName}] ;
opens PackageName [to ModuleName {, ModuleName}] ;
uses TypeName ;
provides TypeName with TypeName {, TypeName} ;
Java Language Specification, Java SE 9 Edition

Class Loaders
• Few restrictions on the relationships between modules and class loaders:
– A class loader can load types from one module or from many modules
• as long the modules do not interfere with each other and
• the types in any particular module are loaded by just one loader
• Critical to compatibility
– retains the existing hierarchy of built-in class loaders.
• Easier to modularize existing applications with complex class loaders
– class loaders can be upgraded to load types in modules
– without necessarily changing their delegation patterns
42

Modular Class Loading in JDK 9
43

Layers
44

Layer creation
45
(2)
String moduleName -> {
switch (moduleName) {
case “java.base“:
case “java.logging“:
return BOOTSTRAP_LDR;
default:
return APP_LDR;
}
}
(1)

Unnamed Modules
• Every class loader has a unique unnamed module
– returned by the new ClassLoader::getUnnamedModule method
• A class loader loads a type not defined in a named module
– that type is considered to be in the unnamed module
• An unnamed module
– reads every other module
– exports all of its packages to every other module
• Existing class-path applications using only standard APIs can keep working
46
Backwards compatibility: Loading types from the class path

Während der Übergangszeit bleibt diese Hintertür offen
At your own risk: java launcher and javac option, as part of JEP 261: Module System
47
• --add-exports <source-module>/<package>=<target-module>(,<target-module>)*
where <source-module> and <target-module> are module names and <package> is the name of a package
• --add-exports java.management/com.sun.jmx.remote.internal=jmx.wbtest
• --add-exports java.management/sun.management=ALL-UNNAMED
The --add-exports option must be used with great care. You can use it to gain access to an internal API of
a library module, or even of the JDK itself, but you do so at your own risk: If that internal API changes or
is removed then your library or application will fail.

Jigsaw and the tools
• jimage
• jdeps
• jlink

jimage – Modulverzeichnis-Kommando (1)
C:jdk-9> java –version
java version "9.0.4"
Java(TM) SE Runtime Environment (build 9.0.4+11)
Java HotSpot(TM) 64-Bit Server VM (build 9.0.4+11, mixed mode)
C:jdk-9lib> jimage info modules
C:jdk-9lib> jimage list modules
/* list all JDK 9 *.class files from the modules file */
C:jdk-9lib> jimage extract --dir=C:jdk-9mydir modules
/* extract all JDK 9 *.class files from the libmodules file */
C:jdk-9> java --list-modules
/* list the JDK 9 modules */
Tools should never read jimage files, directly or via code. It’s an JVM-internal format ..

jimage – Modulverzeichnis-Kommando (2)
• JIMAGE Format
Schneller Zugriff auf die im JDK 9 enthaltene Klassen
Kein langsames Durchsuchen von ZIP-Einträgen
JIMAGE für beschleunigtes Klassenladen innerhalb vom JDK
• JMOD Format
Basiert auf dem ZIP-Format, wie das JAR-Format
Für modulspezifische Metadaten und plattformspezifische Bibliotheken (DLL‘s oder SO-Files)
JMOD Format soll künftig Ersatz für das JAR-Format werden, damit komplette Java-Anwendungen als Modul ausgeliefert werden
können, inklusive allen Metadaten von Abhängigkeiten und exportierten API‘s
Anwendungs-Rollout mit abgespeckter JRE, nur mit den benötigten Modulen
Q: Without it, how can org.reflections and scannotations efficiently find all classes that have specific annotation?
A: Tools should use the jrt filesystem to scan classes in the image. Details in JEP 220: http://openjdk.java.net/jeps/220
Tools should never read jimage files, directly or via code. It’s an JVM-internal format ..

jdeps - Java-Class-Dependency-Analyzer
C:mlib> jdeps -profile com.greetings.jar
com.greetings
[file:///C:/mlib/com.greetings.jar]
requires mandated java.base (@9-ea)
com.greetings -> java.base (compact1)
com.greetings -> java.io compact1
com.greetings -> java.lang compact1
C:mlib> jdeps -v com.greetings.jar
com.greetings
[file:///C:/mlib/com.greetings.jar]
requires mandated java.base (@9-ea)
com.greetings -> java.base
com.greetings.Main -> java.io.PrintStream java.base
com.greetings.Main -> java.lang.Object java.base
com.greetings.Main -> java.lang.String java.base
com.greetings.Main -> java.lang.System java. base

jdeps - Java-Class-Dependency-Analyzer JDK 9.0.4 (1)
C:jdk-9JavaFXApplication9dist> jdeps -profile JavaFXApplication9.jar
JavaFXApplication9.jar -> java.base (compact1)
JavaFXApplication9.jar -> javafx.base (javafx.base)
JavaFXApplication9.jar -> javafx.controls (javafx.controls)
JavaFXApplication9.jar -> javafx.graphics (javafx.graphics)
javafxapplication9 -> java.io compact1
javafxapplication9 -> java.lang compact1
javafxapplication9 -> javafx.application
javafxapplication9 -> javafx.collections
javafxapplication9 -> javafx.event
javafxapplication9 -> javafx.scene
javafxapplication9 -> javafx.scene.control
javafxapplication9 -> javafx.scene.layout
javafxapplication9 -> javafx.stage
C:jdk-9JavaFXApplication3dist> jdeps -v JavaFXApplication9.jar
C:jdk-9JavaFXApplication9dist> jdeps --generate-module-info C:jdk-9JavaFXApplication9dist
c:jdk-9JavaFXApplication9distJavaFXApplication9.jar
writing to C:jdk-9JavaFXApplication9distJavaFXApplication9module-info.java

C:jdk-9JavaFXApplication9dist> jdeps --generate-module-info C:jdk-9JavaFXApplication9dist
c:jdk9JavaFXApplication9distJavaFXApplication9.jar
writing to C:jdk-9JavaFXApplication9distJavaFXApplication9module-info.java
C:jdk-9JavaFXApplication9distJavaFXApplication9> dir
18.01.2018 22:22 171 module-info.java
C:jdk-9JavaFXApplication9distJavaFXApplication9> type module-info.java
module JavaFXApplication9 {
requires javafx.base;
requires javafx.controls;
requires transitive javafx.graphics;
exports javafxapplication9;
}

C:jdk-9JavaFXApplication9dist> jdeps --module-path C:jdk-9JavaFXApplication9dist -s -dotoutput
c:jdk-9JavaFXApplication9dist c:jdk-9JavaFXApplication9distJavaFXApplication9.jar
C:jdk-9JavaFXApplication9dist> type summary.dot
digraph "summary" {
"JavaFXApplication9.jar" -> "java.base (java.base)";
"JavaFXApplication9.jar" -> "javafx.base (javafx.base)";
"JavaFXApplication9.jar" -> "javafx.controls (javafx.controls)";
"JavaFXApplication9.jar" -> "javafx.graphics (javafx.graphics)";
}
http://www.webgraphviz.com/

Additional diagnostic options supported by the launcher include
java --show-module-resolution to show module resolution output during startup, and
causes the module system to describe its activities as it constructs the initial module graph
C:jdk-9> java --show-module-resolution|more
root jdk.jdi jrt:/jdk.jdi
root javafx.web jrt:/javafx.web
root jdk.xml.dom jrt:/jdk.xml.dom
root jdk.jfr jrt:/jdk.jfr
root jdk.packager.services jrt:/jdk.packager.services
root jdk.httpserver jrt:/jdk.httpserver
root javafx.base jrt:/javafx.base
root jdk.net jrt:/jdk.net
root javafx.controls jrt:/javafx.controls
root java.se jrt:/java.se
root jdk.compiler jrt:/jdk.compiler
root jdk.jconsole jrt:/jdk.jconsole
root jdk.plugin.dom jrt:/jdk.plugin.dom
root jdk.attach jrt:/jdk.attach
root jdk.javadoc jrt:/jdk.javadoc
root jdk.jshell jrt:/jdk.jshell
root oracle.desktop jrt:/oracle.desktop
root jdk.sctp jrt:/jdk.sctp
root jdk.jsobject jrt:/jdk.jsobject
root javafx.swing jrt:/javafx.swing
root jdk.packager jrt:/jdk.packager
Since JDK 9 ea build 166:
“Also since early builds, `-Xdiag:resolver`
was the option to print resolver diagnostic
messages. This really odd option has now being
replaced with `--show-module-resolution` to
show resolution during startup.
The output has been cleaned up to make it
easier to read and search.”

jlink - generiert JRE und Applikations-Images (1)
• Platzsparende Runtime, inklusive eigener Anwendungsmodule im frei wählbaren Verzeichnis
jlink <options> --module-path <modulepath> --output <path>
jlink --module-path $JDKMODS:mlib --add-modules myapp --output myimage
C:> jlink --module-path C:jdk-9jmods;mlib --add-modules com.greetings --compress=2 --
verbose --output greetingsapplication
com.greetings file:///C:/mlib/com.greetings.jar
java.base file:///C:/jdk-9/jmods/java.base.jmod
Providers: java.base provides java.nio.file.spi.FileSystemProvider used by java.base

• Image-Verzeichnis C:greetingsapplication 24 MB
• Datei release mit früherem „build 9-ea+142-jigsaw-nightly-h5677-20161102”
C:greetingsapplication> dir
Directory of C:greetingsapplication
18.01.2018 18:35 <DIR> .
18.01.2018 18:35 <DIR> ..
18.01.2018 18:35 <DIR> bin
18.01.2018 18:35 <DIR> conf
18.01.2018 18:35 <DIR> include
18.01.2018 18:35 <DIR> legal
18.01.2018 18:35 <DIR> lib
18.01.2018 18:35 57 release
#Thu Mar 09 22:11:23 CET 2017
OS_NAME="Windows"
MODULES="java.base com.greetings"
OS_VERSION="5.1"
OS_ARCH="i586"
JAVA_VERSION="9"
JAVA_FULL_VERSION="9-ea"
• Datei release „9.0.4“
JAVA_VERSION="9.0.4"
MODULES="java.base com.greetings"

C:greetingsapplicationbin> java -m com.greetings/com.greetings.Main
Greetings!
C:greetingsapplicationbin> dir
18.01.2018 18:35 143.360 java.dll
18.01.2018 18:35 225.280 java.exe
18.01.2018 18:35 225.792 javaw.exe
18.01.2018 18:35 19.968 jimage.dll
18.01.2018 18:35 195.072 jli.dll
18.01.2018 18:35 10.752 keytool.exe
18.01.2018 18:35 660.128 msvcp120.dll
18.01.2018 18:35 963.232 msvcr120.dll
18.01.2018 18:35 89.600 net.dll
18.01.2018 18:35 53.760 nio.dll
18.01.2018 18:35 <DIR> server
18.01.2018 18:35 43.008 verify.dll
18.01.2018 18:35 70.144 zip.dll
C:mlib> java -jar com.greetings.jar
Greetings!

C:greetingsapplicationbin> java -m com.greetings/com.greetings.Main
Greetings!
C:greetingsapplicationbin> java --show-module-resolution -m com.greetings/com.greetings.Main
root com.greetings jrt:/com.greetings
Greetings!
C:greetingsapplicationbin> java --list-modules -m com.greetings/com.greetings.Main
com.greetings
java.base@9.0.4
C:greetingsapplicationbin> java -verbose -m com.greetings/com.greetings.Main
C:greetingsapplicationbin>
java --add-exports java.base/jdk.internal.ref=ALL-UNNAMED -m com.greetings/com.greetings.Main
Greetings!

• Sources per JDK
service
java ..
java-8 ..
java-9
org.gradle.example.service
Service9
• Dependencies per JDK
sources {
java8 ..
java9 {
dependencies {
library ‘org.apache.httpcomponents:httpclient:4.5.1‘
}
}
}
60
JSR 376: Java Platform Module System – Gradle (1)
Integration with developer tools (Maven, Gradle, IDE‘s)

• JEP 238: Multi-Release JAR
jar root
– A.class
– B.class
– C.class
– D.class
– META-INF
– versions
– 8
– A.class
– B.class
– 9
– A.class
– 10
– A.class
–}
61
JSR 376: Java Platform Module System – Gradle (2)
• A multi-release JAR "MRJAR" will contain
additional directories for classes and resources
specific to particular Java platform releases.
• A JAR for a typical library might look like this:
jar root
– A.class
– B.class
– C.class
– D.class

JSR 376: Java Platform Module System – NetBeans IDE (1)

JSR 376: Java Platform Module System – NetBeans IDE (2)
http://bits.netbeans.org/download/trunk/nightly/latest/
C:Program FilesNetBeans Dev 201703140002
C:Program FilesJavajdk1.8.0_161 64-bit
JDK 9.0.4
http://wiki.netbeans.org/JDK9Support#JDK9_EA_Support

Zusammenfassung
64
Die Modularisierung der Java SE Plattform im JDK 9 bringt viele Vorteile, aber auch
größere Änderungen
Existierender Anwendungs-Code, der nur offizielle Java SE Plattform-API‘s mit den
unterstützten JDK-spezifischen API’s verwendet, soll auch weiterhin ohne Änderungen
ablauffähig sein
Abwärtskompatibilität
Dennoch ist es wahrscheinlich, wenn weiterhin veraltete Funktionalität oder JDK-interne API’s
verwendet werden, dass der Code unverträglich sein kann
Entwickler sollten sich frühzeitig damit vertraut machen, wie existierende Bibliotheken &
Anwendungen auf JDK 9 anzupassen sind, sie modularisiert werden, welche Designfragen
zu klären sind und wie man vorhandenen Anwendungs-Code trotzdem mit JDK 9 zum
Laufen bekommt, auch wenn man diesen nicht verändern kann

Danke!
Wolfgang.Weigend@oracle.com
Twitter: @wolflook
65

JDK 9 Java Platform Module System

More Related Content

What's hot

Similar to JDK 9 Java Platform Module System

More from Wolfgang Weigend

Recently uploaded

JDK 9 Java Platform Module System