Project Jigsaw – Modularity
at language level
Kamil Korzekwa
@kamkorz | blog.kamkor.me April 14, 2016

Project Jigsaw
• Adds modularity to the Java
platform
• Hopefully coming to JDK 9 in
March 2017
• Will cause compatibility issues
for applications that use JDK
internal APIs (JEP 260)

How is it different from tools like Maven?
Jigsaw is language level mechanism!

What’s a jigsaw module?
• A grouping of code
• For example Java packages
• Can contain other data such as
• resources
• configuration files
• native code (for example when using JNI)
• Defined in the module-info.java file
• File is placed in the root of the module folder
• Can be packaged as jar

module-info.java file
• Module has a symbolic name (that only looks like a package)
• Module exports packages (public API) to other modules
• Module requires dependencies to other modules
module me.kamkor.foo {
exports me.kamkor.foo.api;
exports me.kamkor.foo;
requires java.sql;
}
Current naming
convention
Same as module
name, confusing
enough?

public != accessible (fundamental change to Java)
• public
JDK9
• public to everyone
module me.kamkor.foo {
exports me.kamkor.foo.api;
}
• public, but only to specific modules
module me.kamkor.foo {
exports me.kamkor.foo.api to
me.kamkor.bar,
me.kamkor.magic;
}
• public only within a module
PRE-JDK9

Implied readability
module me.kamkor.foo {
requires java.sql;
}
• Code in the me.kamkor.foo module:
final Driver driver = DriverManager.getDriver(url);
final Logger logger = driver.getParentLogger();
logger.info(“Connection acquired”);
Logger is exported in
the java.logging module
Driver is exported in
the java.sql module

Implied readability
// assumed configuration (fake)
module java.sql {
requires java.logging;
..
}

Implied readability
module java.sql {
requires public java.logging;
}

Implied readability
• If you use types from required module in your exported types, then
consider exposing this module to your users using requires public
• If you use types from required module only in your internal code,
then do not expose this module to your users

“Fun” with classpath
bin/greeter/GreetingProvider.class
bin/starwarsgreeter/GreetingProvider.class
bin/app/GreeterApp.class
Using default package
for the sake of simplicity

“Fun” with classpath
$ java -classpath bin/greeter:bin/app GreeterApp
Hello World
$ java -classpath bin/starwarsgreeter:bin/app GreeterApp
May the force be with you!
$ java -classpath bin/greeter:bin/starwarsgreeter:bin/app GreeterApp
Hello World

Classpath hell – shadowing
• Default classloader loads the first matching class it finds
"The order in which you specify multiple class path entries is important.
The Java interpreter will look for classes in the directories in the order
they appear in the class path variable.”
https://docs.oracle.com/javase/8/docs/technotes/tools/windows/class
path.html

Classpath hell – real world examples of
shadowing
• Different libraries on the classpath contain class with the
same fully qualified name
• Two different versions of the same library are on the
classpath
• Library is renamed and accidentally added to the classpath
twice

Modulepath to the rescue!

Classpath vs modulepath
• Flat structure
• Allows to locate individual types
• Default classloader loads the
first matching class it finds on
the classpath
Modulepath
• Graph structure
• Allows to locate modules rather
than individual types
• Java is aware about relationships
between the modules
• Can discover potential problems
sooner
Classpath

Shadowing fixed with Jigsaw modulepath
• Compiling Java application with two modules on the modulepath that
export the same package
src/me.kamkor.foo/module-info.java:1: error:
module me.kamkor.foo reads package me.kamkor.beta from both
me.kamkor.bar1 and me.kamkor.bar2
Compile error

Shadowing fixed with Jigsaw modulepath
• Running Java application with two modules on the modulepath that
have the same name
Error occurred during initialization of VM
java.lang.module.ResolutionException: Two versions of module
me.kamkor.bar found in mods
Error when trying to
run application

Module version selection
• Version selection is left for the dependency-resolution
mechanisms such as Maven, Gradle, sbt etc.
http://openjdk.java.net/projects/jigsaw/goals-reqs/03#version-
selection

Multiple module versions
• Jigsaw allows only one
version of module in single
configuration
• Dependency resolution
mechanism must pick one
• Modulepath version hell just
like classpath version hell
http://openjdk.java.net/projects
/jigsaw/goals-reqs/03#version-
selection

Circular dependencies
module me.kamkor.foo {
requires me.kamkor.bar;
}
module me.kamkor.bar {
requires me.kamkor.foo;
}
./src/me.kamkor.foo/module-info.java:2: error: cyclic
dependence involving me.kamkor.bar requires me.kamkor.bar;
Compile error

Better JDK with the use of Project Jigsaw

JDK is BIG!
• 4000+ classes in rt.jar
(classes.jar on Macs)
• java.util.List etc.
• All loaded on start by the
bootstrap classloader
• Does your application really
need all of them?
(source: Liguori, R., Liguori, P.: Java 8 Pocket Guide)

JDK will be split into modules
http://openjdk.java.net/jeps/200

JDK Structure (simplified)
bin
java
javac
jre
bin java
lib rt.jar
lib tools.jar
JDK9
bin
java
javac
conf
jmods
lib
Pre-JDK9
jre directory
rt.jar
tools.jar

jlink – The Java Linker
“Create a tool that can assemble and optimize a set of modules and
their dependencies into a custom run-time image as defined in JEP
220.”
http://openjdk.java.net/jeps/282

jlink – The Java Linker
$ jlink --modulepath $JAVA_HOME/jmods:mlib
--addmods me.kamkor.greeter --output executable
--strip-debug --compress=2
$ tree –L 1 executable
executable
bin
conf
lib

jlink – The Java Linker
$ du -h -d 0 executable
20M executable
$ executable/bin/me.kamkor.greeter
Greetings World!

jlink – The Java Linker
$ executable/bin/java -listmods
java.base@9-ea
me.kamkor.greeter
me.kamkor.foo@1.0
Version is just
for information
purposes

Compatibility & Migration
• Applications can still use classpath
• JDK will be split into modules. Applications may be affected if they
used internal APIs of the JDK (JEP 260)
• Applications can be split into Jigsaw modules in small steps. Migration
guide:
• http://openjdk.java.net/projects/jigsaw/spec/sotms/#compatibility--
migration

Project Jigsaw summary
• Improved maintainability of JDK and user applications
• Stronger encapsulation (modules export public APIs)
• Reliable configuration with modulepath that replaces error prone classpath
mechanism
• Improved security of applications
• Less APIs make the attack surface smaller
• Improved Java platform scalability and flexibility
• Configurable modular JDK
• Run-time images (jlink – the Java Linker tool)
• Improved performance of applications
• Start up performance improvements (less classes to load by the bootstrap
classloader)

Impact of Project Jigsaw
• I hope that it will speed up the development of the JDK
• Will it be widely adopted by the developers?
• Spring 5 will support Jigsaw out of the box
• Spring will do everything it can to allow you to use Jigsaw
• Spring jars (spring-mvc, spring-jdbc etc.) will be configured as Jigsaw modules
• http://www.infoq.com/presentations/spring-framework-5

Useful resources
• https://github.com/AdoptOpenJDK/jdk9-jigsaw
• http://openjdk.java.net/projects/jigsaw/spec/sotms/
• http://openjdk.java.net/projects/jigsaw/

Thank you, questions?