Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

Java SE 9 modules (JPMS) - an introduction

An introduction to the Java Platform Module System (JPMS). This talk is from April 2017, before the Java SE 9 release, so the final details may be subtly different, particularly once a standard becomes established for module names.

4.
Modules
● JPMS - Java Platform Module System
● Main feature of Java SE 9
● Developed as Project Jigsaw
● Originally targetted at Java SE 7
○ first JSR was in 2005, 12 years ago
● Still incomplete even though very late in 9 development
● Planned release date of July 27th 2017
○ just over 100 days!

16.
Questions
● What happens if class not found on classpath?
● What happens if class appears twice on classpath?
● Does order matter in the classpath?
● What happens if same class is loaded by two different
class loaders?

17.
Classpath
Once on the classpath
● A can call B and vice versa
● A can call C and vice versa
● B can call C and vice versa
Jar files meaningless
A.class
B.class
C.class

19.
Packages are all we have
● Applications & libraries need to be multi-package
● More things public than desirable
● Often see packages with "impl" or "internal" in name
● Clear sign of a missing language feature

24.
What is a module?
● Named
● Set of packages (classes/interfaces)
● Module metadata (module-info.class)
● Typically packaged as a .jar file
● Enforced by the JVM
○ JVM understands classes, interfaces, packages, and now modules

30.
How is it enforced
● Modulepath as well as classpath
● Jar must have a module-info.class
● Module rules enforced when jar on modulepath
● Rules not enforced when jar on classpath
● JVM determines and validates module graph
○ checked at startup
○ advanced use cases can alter parts of the graph at runtime

42.
Checks
● Module path contains a set of modules
● One module is the root
● Other modules are resolved to form a graph
● System ensures all necessary modules are available
● System ensures no module found twice
● System ensures same package not in two modules
● System ensures graph has no cycles

43.
Modulepath
● A coherent modulepath is your problem
● Versions, and their selection, not part of JPMS
○ do not put version in module name
● Typically will be done by Maven or Gradle
● Just like the classpath is assembled today
Open to debate as to how much this achieves
the reliable configuration requirement

48.
Access
● Only exported packages are visible to other modules
● All other packages are private to the module
● "public" no longer means "public"
● Other modules can only see and use code if:
○ public
○ package is exported by target module
○ package is readable from this module
● Combination referred to as "accessibility"

57.
Reflection
open module joda.beans {
// other modules this module depends on
requires transitive joda.convert;
// packages this module exports to other modules
exports org.joda.beans;
}
● Modules can open all packages if desired

58.
Reflection on the JDK
● JDK is fully modular
● JDK does not have "open" packages
● Thus, cannot reflect on non-public JDK
● Big security boost
● Breaks many existing libraries
● Can use command line flags to force JDK open
○ useful in the short term until the libraries are fixed

59.
Reflecting on modules
● Module information is available to reflection
○ new Module class and getModule() method
○ allows the JVM module graph to be accessed
● See also the ModuleLayer concept
○ intended for advanced use cases

61.
Migration
● Take existing code and migrate it
● New rules make this tricky in some cases
○ eg. SLF4J will need major rework

62.
Use classpath
● Most existing code will run on Java SE 9 classpath
● If it uses internal JDK API, fix or use a flag:
○ --add-exports, --add-opens, --permit-illegal-access
● If it uses removed JDK module, fix or use a flag:
○ --add-modules java.xml.bind

67.
Migration
● Additional "automatic module" concept
● Jars without module-info on modulepath
● Exports all packages in jar
● Reads the all other modules, including unnamed
● Used to handle libraries that have not yet modularized
WARNING! There are serious concerns about
using automatic modules in open source projects.
Maven Central will likely ban projects that depend
on an automatic module.

69.
Module naming
● No agreement on module names yet
● Please wait until clear convention agreed
● Might be like package names
○ org.joda.convert
● Might be shorter, but this will lead to clashes
○ joda.convert
WARNING! There are still serious naming concerns
from the open source community.

70.
Modules and Maven
● Maven creates a tree of dependencies
● Often enforced by IDEs
● Not enforced at runtime
● Likely that each pom.xml will be a JPMS module
○ unclear whether module-info.java will be hand written
○ or derived from pom.xml (I suspect hand written, with IDE help)
● JPMS does not handle versions
● JPMS does not select jar files from Maven repo

71.
Modules and OSGi
● OSGi is a module system based on the classpath
● It still works fine on the classpath
● Dynamic loading, lifecycle etc. not part of JPMS
● JPMS is not ClassLoader based
○ all classes in a module have the same ClassLoader
○ same ClassLoader may be used by many modules

73.
Summary
● Modules are a new JVM concept, exposed in Java
○ don't confuse with Maven, OSGi, JBoss modules
● Moving to modules is non-trivial
○ no reflection on JDK internals without command line flag
○ parts of the JDK removed by default and need command line flag
● Reflection is being restricted
○ command line flags allow this to be broken
● Don't rush to modularize!
○ wait for open source to do so first