JAVA 9 JIGSAW HACK DAY
JAVA 9 JIGSAW
JUG Kyiv 2017
@Oleg Tsal-Tsalko JUG Kyiv 2017
SOLUTION ARCHITECT AT EPAM SYSTEMS.
PATIONATE DEVELOPER, SPEAKER, ACTIVE MEMBER OF
PARTICIPATE IN DIFFERENT EDUCATIONAL INITIATIVES,
ENGINEERING EVENTS AND JCP/ADOPTJSR PROGRAMS.
•Intro into Java 9 Module System (~1h)
•VJUG Hacking Session replay hands-on labs (~2h)
•JUnit 5 platform migration case study (~3h)
• 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))
As described in the JSR, the speciﬁc goals of the
module system are to provide
• Reliable conﬁguration, 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.
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
What is module?
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
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
• the second module reads the first
• 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
Application’s universe of observable modules can consist of:
•named platform modules as they are contained in the run
•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)