Project Jigsaw in JDK9

© Copyright Azul Systems 2016
@speakjava
Project Jigsaw in JDK 9:
Modularity Comes To Java
Simon Ritter
Deputy CTO, Azul Systems
1

Agenda
 API structure changes
 Introduction to Jigsaw
 Developing code with modules
 Application migration
 Resources
2

API Structure Changes

API Classification
 Supported, intended for public use
– JCP specified: java.*, javax.*
– JDK specific: some com.sun.*, some jdk.*
 Unsupported, not intended for public use
– Mostly sun.*
– Most infamous is sun.misc.Unsafe
4

General Java Compatability Policy
 If an application uses only supported APIs on version N of
Java it should work on version N+1, even without
recompilation
 Supported APIs can be removed, but only with advanced
notice
 To date 23 classes, 18 interfaces and 379 methods have
been deprecated
–None have been removed
5

JDK 9: Incompatible Changes
 Encapsulate most JDK internal APIs
 Remove a small number of supported APIs
– 6 in total, all add/remove PropertyChangeListener
– Already flagged in JSR 337 (Java SE 8), JEP 162
 Change the binary structure of the JRE and JDK
 New version string format
 A single underscore will no longer be allowed as an
identifier in source code
6

Removed In JDK 9
 Endorsed standard API override mechanism
 Extension mechanism
 No longer required now we have a module system
7

Binary Structure Of JDK/JRE
 Potentially disruptive change
– Details in JEP 220
– Blurs the distinction between JRE and JDK
 Implemented since late 2014
– Allow people to get used to new organisation
8

JDK Structure
bin
Pre-JDK 9 JDK 9
lib
tools.jar
jre
bin
rt.jar
lib
libconfbin
jre directory
tools.jar
rt.jar

Most Popular Unsupported APIs
1. sun.misc.BASE64Encoder
2. sun.misc.Unsafe
3. sun.misc.BASE64Decoder
10
Oracle dataset based on internal application code

JDK Internal API Classification
 Non-critical
– Little or no use outside the JDK
– Used only for convenience (alternatives exist)
 Critical
– Functionality that would be difficult, if not impossible to
implement outside the JDK
11

JEP 260 Proposal
 Encapsulate all non-critical JDK-internal APIs
 Encapsulate all critical JDK-internal APIs, for which
supported replacements exist in JDK 8
 Do not encapsulate other critical JDK-internal APIs
– Deprecate these in JDK 9
– Plan to encapsulate or remove them in JDK 10
– Provide command-line option to access encapsulated
critical APIs
12

JEP 260 Accessible Critical APIs
 sun.misc.Unsafe
 sun.misc.Signal
 sun.misc.SignalHandler
 sun.misc.Cleaner
 sun.reflect.Reflection.getCallerClass
 sun.reflect.ReflectionFactory
13

Reviewing Your Own Code
 jdeps tool
– Introduced in JDK 8, improved in JDK 9
– Maven jdeps plugin
jdeps –jdkinternals path/myapp.jar
14
path/myapp.jar -> /opt/jdk1.8.0/jre/lib/rt.jar
<unnamed> (myapp.jar)
-> java.awt
-> java.awt.event
-> java.beans
-> java.io
...

Introduction To Jigsaw And
Modules

Goals For Project Jigsaw
 Make Java SE more scalable and flexible
 Improve security, maintainability and performance
 Simplify construction, deployment and maintenance of
large scale applications
 Eliminate classpath hell
16

Modularity Specifications
 Java Platform Module System
– JSR 376: Targeted for JDK 9 (no promises)
 Java SE 9: New JSR will cover modularisation of APIs
 OpenJDK Project Jigsaw
 Reference implementation for JSR 376
 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
17

Module Fundamentals
 Module is a grouping of code
– For Java this is a collection of packages
 The module can contain other things
– Native code
– Resources
– Configuration data
18
com.azul.zoop
com.azul.zoop.alpha.Name
com.azul.zoop.alpha.Position
com.azul.zoop.beta.Animal
com.azul.zoop.beta.Zoo

Module Declaration
19
module com.azul.zoop {
}
module-info.java
com/azul/zoop/alpha/Name.java
com/azul/zoop/alpha/Position.java
com/azul/zoop/beta/Animal.java
com/azul/zoop/beta/Zoo.java

Module Dependencies
requires com.azul.zeta;
} com.azul.zoop
com.azul.zeta

Module Dependencies
module com.azul.app {
requires com.azul.zoop
requires java.sql
}
com.azul.app
com.azul.zoop java.sql

Module Dependency Graph
com.azul.app
java.base
java.sqlcom.azul.zoop
com.azul.zeta
java.xml java.logging
explicit
implicit

Readability v. Dependency
com.azul.app
java.sql
java.logging
module java.sql {
requires public java.logging;
}
Driver d = …
Logger l = d.getParentLogger();
l.log(“azul’);

Module Implied Readability Graph
com.azul.app
java.base
java.sqlcom.azul.zoop
com.azul.zeta
java.xml java.logging

Package Visibility
exports com.azul.zoop.alpha;
exports com.azul.zoop.beta;
}
com.azul.zoop
com.azul.zoop.alpha
com.azul.zoop.beta com.azul.zoop.theta

Accessibility
 For a package to be visible
– The package must be exported by the containing module
– The containing module must be read by the using module
 Public types from those packages can then be used
com.azul.zoopcom.azul.app
reads

Java Accessibility (pre-JDK 9)
public
protected
<package>
private

Java Accessibility (JDK 9)
public to everyone
public, but only to specific modules
public only within a module
protected
<package>
private
public ≠ accessible (fundamental change to Java)

JDK Platform Modules
29

Developing Code With
Modules

Compilation
31
$ javac –d mods
src/zeta/module-info.java
src/zeta/com/azul/zeta/Vehicle.java
mods/zeta/module-info.class
mods/zeta/com/azul/zeta/Vehicle.class
src/zeta/module-info.java
src/zeta/com/azul/zeta/Vehicle.java

Module Path
$ javac –modulepath dir1:dir2:dir3

Compilation With Module Path
33
$ javac –modulepath mods –d mods
src/zoop/module-info.java
src/zoop/com/azul/zoop/alpha/Name.java
mods/zoop/module-info.class
mods/zoop/com/azul/zoop/alpha/Name.class
src/zoop/module-info.java
src/zoop/com/azul/zoop/alpha/Name.java

Application Execution
 -modulepath can be abbreviated to -mp
$ java –mp mods –m com.azul.app/com.azul.app.Main
Azul application initialised!
module name main class

Packaging With Modular JAR Files
mods/zoop/module-info.class
mods/zoop/com/azul/app/Main.class
$ jar --create --file myLib/app.jar
--main-class com.azul.zoop.Main
-C mods .
module-info.class
com/azul/zoop/Main.class
app.jar

JAR Files & Module Information
$ jar --file myLib/app.jar –p
Name:
com.azul.zoop
Requires:
com.azul.zeta
java.base [MANDATED]
java.sql
Main class:
com.azul.zoop.Main

Application Execution (JAR)
$ java –mp mylib:mods –m com.azul.zoop.Main
Azul application initialised!

Linking
Modular run-time
image
…confbin
jlink
$ jlink --modulepath $JDKMODS
--addmods java.base –output myimage
$ myimage/bin/java –listmods
java.base@9.0

Linking An Application
$ jlink --modulepath $JDKMODS:$MYMODS
--addmods com.azul.app –output myimage
$ myimage/bin/java –listmods
java.base@9.0
java.logging@9.0
java.sql@9.0
java.xml@9.0
com.azul.app@1.0
com.azul.zoop@1.0
com.azul.zeta@1.0
Version numbering for
information purposes
only

Application Migration

Typical Application (JDK 8)
jar
jar
jar
JDK
jar
jarjar
jar jar
jar
jar
jar
jar
Classpath

Typical Application (JDK 9)
jar
jar
jar
module
java.base
module
java.desktop
module
java.datatransfer
module
java.xml
jar
jarjar
jar jar
jar
jar
jar
jar
Unnamed
module

Sample Application
myapp.ja
r
lwjgl.jar
mylib.jar
gluegen-rt.jar jogl-all.jar
module
java.base
module
java.desktop
module
java.datatransfer
module
java.xml

Run Application With Classpath
$ java –classpath
lib/myapp.jar:
lib/mylib.jar:
lib/liblwjgl.jar:
lib/gluegen-rt.jar:
lib/jogl-all.jar:
myapp.Main

Sample Application
module
myapp.ja
r
lwjgl.jar
module
mylib.jar
gluegen-rt.jar jogl-all.jar
module
java.base
module
java.desktop
module
java.datatransfer
module
java.xml

Application module-info.java
module myapp {
requires mylib;
requires java.base;
requires java.sql;
requires lwjgl; ????
requires gluegen-rt; ????
requires jogl-all; ????
}

Sample Application
module
myapp.ja
r
module
lwjgl.jar
module
mylib.jar
module
gluegen-rt.jar
module
jogl-all.jar
module
java.base
module
java.desktop
module
java.datatransfer
module
java.xml

Automatic Modules
 Real modules
 Simply place unmodified jar file on module path
– Rather than classpath
 No changes to JAR file
 Module name derived from JAR file name
 Exports all its packages
– No selectivity
 Automatically requires all modules on the module path
48

Application Module Dependencies
module
myapp.ja
r
module
lwjgl.jar
module
mylib.jar
module
gluegen-rt.jar
module
jogl-all.jar
module
java.base
module
java.desktop
module
java.datatransfer
module
java.xml
Implicit
Explicit

Run Application With Modules
$ java –classpath
lib/myapp.jar:
lib/mylib.jar:
lib/liblwjgl.jar:
lib/gluegen-rt.jar:
lib/jogl-all.jar:
myapp.Main
$ java –mp mylib:lib –m myapp

Summary & Further Information

Summary
 Modularisation is a big change for Java
– JVM/JRE rather than language/APIs
 Potentially disruptive changes to exposure of non-public APIs
– Is it safe?
 Developing modular code will require some learning
– Not a huge change, though
52

Further Information
 openjdk.java.net
 openjdk.java.net/jeps
 openjdk.java.net/projects/jigsaw
 jcp.org
www.zulu.org
54

@speakjava
Questions
Simon Ritter
Deputy CTO, Azul Systems
55

Project Jigsaw in JDK9

Recommended

More Related Content

What's hot (20)

Viewers also liked (7)

Similar to Project Jigsaw in JDK9 (20)

More from Simon Ritter (20)

Recently uploaded (20)

Project Jigsaw in JDK9

Editor's Notes