This is slides from JUG UA HackDay meetup organised on 12 Aug 2017

1. JAVA 9 JIGSAW HACK DAY
JAVA 9 JIGSAW
HACK DAY
Oleg Tsal-Tsalko
JUG Kyiv 2017
@Oleg Tsal-Tsalko JUG Kyiv 2017

2. SOLUTION ARCHITECT AT EPAM SYSTEMS.
PATIONATE DEVELOPER, SPEAKER, ACTIVE MEMBER OF
KIEV JUG.
PARTICIPATE IN DIFFERENT EDUCATIONAL INITIATIVES,
ENGINEERING EVENTS AND JCP/ADOPTJSR PROGRAMS.
OLEG TSAL-TSALKO
ABOUT ME

3. CONFIDENTIAL 3
TBFD Agenda
•Intro into Java 9 Module System (~1h)
•VJUG Hacking Session replay hands-on labs (~2h)
•Launch (~30min)
•JUnit 5 platform migration case study (~3h)

4. CONFIDENTIAL 4
TBFD Expectations
• It’s not an ultimate guide to Modules System. Our goal is to understand what it is
and try to use it.
• We gonna touch only key aspects of Java Module System that will influence most
of the developers.
• You not gonna write Java code))
• We not gonna touch Maven/Gradle integration with Java 9 Modules System.
• Java 9 is not ready to be used on Production yet!
• I’m not an expert))

5. CONFIDENTIAL 5
TBFD Links and Materials
• https://github.com/olegts/jdk9-jigsaw/tree/jug - VJUG hacking session materials
• https://github.com/olegts/junit5/tree/hackday - JUnit 5 modularizing
• https://docs.google.com/document/d/
11JxkGH4Em0thovKojITM1oHvi9UmFsdtFw3zDRAKeFQ/edit?usp=sharing - Feedback
form
• https://www.slideshare.net/olegtsaltsalko9/java-9-jigsaw-hackday - Slides link
• http://openjdk.java.net/projects/jigsaw/quick-start - Jigsaw quick start guide
• http://jdk.java.net/jigsaw/ - Java 9 Jigsaw early access build download
• http://junit.org/junit5/docs/current/user-guide/#dependency-diagram - JUnit 5
documentation
• https://www.jetbrains.com/help/idea/2017.1/getting-started-with-java-9-module-
system.html - IntelliJ IDEA Java 9 support

6. CONFIDENTIAL 6
Why do we need Module System?

7. CONFIDENTIAL 7

8. CONFIDENTIAL 8
“are these even the correct JARs?”
“are these all required JARs?”
“are there conflicts?”
“are only public APIs used?”

9. CONFIDENTIAL 9

10. CONFIDENTIAL 10
As described in the JSR, the specific goals of the
module system are to provide
• Reliable configuration, to replace the brittle,
error-prone class-path mechanism with a means
for program components to declare explicit
dependences upon one another, along with
• Strong encapsulation, to allow a component to
declare which of its public types are accessible
to other components, and which are not.
Goals

11. CONFIDENTIAL 11
A module is a named, self-describing collection of
code and data. Its code is organized as a set of
packages containing types, i.e., Java classes and
interfaces; its data includes resources and other
kinds of static information. To control how its code
refers to types in other modules, a module
declares which other modules it requires in order
to be compiled and run. To control how code in
other modules refers to types in its packages, a
module declares which of those packages it
exports.
What is module?

12. CONFIDENTIAL 12
What is modular JAR?
A modular JAR file is like an ordinary JAR
file in all possible ways, except that it also
includes a module-info.class file in its root
directory.

13. CONFIDENTIAL 13

14. CONFIDENTIAL 14

15. CONFIDENTIAL 15

16. CONFIDENTIAL 16
A type in one module is only accessible by
code in another module if:
• the type is public
• the containing package is exported by the
first module
• the second module reads the first
Accessibility

17. CONFIDENTIAL 17
Implied readability

18. CONFIDENTIAL 18
Services
• It’s been around for long time
• Allows loose coupling between Service Providers and Service Consumers
• Services resolved and wired by modular runtime
• ServiceLoader API enhanced
• It’s not a DI

19. CONFIDENTIAL 19
JDK 7 modules

20. CONFIDENTIAL 20
JDK 9 modules

21. CONFIDENTIAL 21
Unnamed module
All JARs left on classpath included in so-called
unnamed module
Rules:
• Exports everything
• Reads all other modules
• Named modules can’t read it

22. CONFIDENTIAL 22
Bottom-up migration

23. CONFIDENTIAL 23
Automatic module
Any JAR placed on module path…
Rules:
• Module name derived from JAR name
• Exports everything
• Reads all other modules including unnamed
module

24. CONFIDENTIAL 24
Top-down migration

25. CONFIDENTIAL 25
Modules universe
Application’s universe of observable modules can consist of:
•named platform modules as they are contained in the run
time
•one named application module for each artifact on the
module path that has a module descriptor
•one automatic module for each artifact on the module path
that does not have a module descriptor
•a unique unnamed module composed of all artifacts on
the classpath, regardless of whether they have module
descriptors or not (with several application class loaders
there would be several unnamed modules)

26. CONFIDENTIAL 26

27. CONFIDENTIAL 27

28. CONFIDENTIAL 28
Compile
javac --module-path mods
-d mods/com.greetings
src/com.greetings/module-info.java
src/com.greetings/com/greetings/Main.java
javac -d mods
--module-source-path src $(find . -name "*.java")

29. CONFIDENTIAL 29
Package
jar --create
--file mlib/org.astro@1.0.jar
--module-version 1.0
-C mods/org.astro .
jar --create
--file mlib/com.greetings.jar
--main-class=com.greetings.Main
-C mods/com.greetings .

30. CONFIDENTIAL 30
Run
java --module-path mods
--module com.greetings/com.greetings.Main
java -p mods
-m com.greetings/com.greetings.Main
java --module-path mlib
--module com.greetings

31. CONFIDENTIAL 31
Compose (JLink)
jlink --module-path ${JAVA_HOME}/jmods:mlib
--add-modules com.greetings
--output executable
executable/bin/java --module com.greetings
com.greetings.Main