These slides briefly describe the java module system introduced in java 9 This presentation was done with @Mahmoud Anouti

1. Java Module System
for Mortals
MahmoudAnouti / Marc Kassis

2. Motivation
• Makes it easier for developers to construct and
maintain libraries and large applications
• Improve the security and maintainability of Java SE
Platform Implementations in general, and the JDK
in particular

3. Motivation
• Enable improved application performance
• Enable the Java SE Platform, and the JDK, to scale
down for use in small computing devices and dense
cloud deployments.

4. Goals of the Module System
Reliable configuration: solve classpath issues
Strong encapsulation: ability to define public APIs for a
component
Scalable Java SE: ability to assemble custom runtime image
Encapsulate internal APIs (sun.* classes)
Improved performance

5. What is a module?
A named, self-describing set of program
components consisting of code (Java classes,
interfaces) and data (resources / config files)

6. What is a module?
classes < packages < modules

7. Module declaration
module-info.java:
1. Module name
2. Required modules (dependencies)
3. Exported packages
module com.example.myapp {
requires com.example.lib;
exports com.example.foo;
exports com.example.foo.bar;
}
(1)
(2)
(3)

8. Module declaration
• Dependencies: A module definition can require other modules to compile
and run.
• Exports: A module can export one or more of its packages for use by other
modules.
Code that accesses API in non-exported packages will fail (both compile and
runtime).

9. Module declaration
• Resources in a module are accessible only by code within that module.
• Services: a module can declare that it uses a service interface whose
implementations may be provided by other modules.
• Resolution:The module system resolves all transitive dependencies
required by an initial module  result is a configuration

10. module-info.java keywords
module A{
requires transitive B;
exports com.example to D;
opens com.example.beans;
opens com.example.private to E;
}

11. Services
module com.example.serviceapi {
exports com.example.myservice;
}
module com.example.serviceimpl {
requires com.example.serviceapi;
provides com.example.myservice.MyServiceInterface with
com.example.impl.MyServiceImpl;
}

12. Services
module com.example.client {
requires com.example.serviceapi;
uses com.example.myservice.MyServiceInterface;
}

13. DEMO

14. Module artifacts
• A module can be packaged into a modularJAR file:
META-INF/
META-INF/MANIFEST.MF
module-info.class
com/example/foo/Main.class
com/example/foo/bar/Bar.class
...

15. Platform modules
java.activation
java.base
java.compiler
java.corba
java.datatransfer
java.desktop
java.instrument
java.logging
java.management
java.management.rmi
java.naming
java.prefs
java.rmi
java.scripting
java.se
java.se.ee
java.security.jgss
java.security.sasl
java.sql
java.sql.rowset
java.transaction
java.xml
java.xml.bind
java.xml.crypto
java.xml.ws
java.xml.ws.annotation
Java SE platform is divided into modules

16. Platform modules
module java.base {
exports java.io;
exports java.lang;
exports java.lang.annotation;
exports java.lang.invoke;
exports java.lang.module;
exports java.lang.ref;
exports java.lang.reflect;
exports java.math;
exports java.net;
exports java.util;
...
}

17. Module path
• The module system resolves modules by locating them in a
module path: sequence of elements, where each element is
either:
 a module artifact (e.g. modular JAR), or
 a directory containing module artifacts
Classpath is still there!

18. DEMO

19. Reliable configuration
module com.example.myapp {
requires com.example.lib;
requires org.apache.commons.io;
}
module com.example.lib {
requires java.sql;
exports com.example.utils;
}

20. Reliable configuration
com.example.myapp
com.example.lib
java.sql
java.xml
java.base
org.apache.commons.io
java.logging

21. Reliable configuration
•Every dependency is fulfilled by precisely one other module
•The module graph is acyclic
•Every module reads at most one module defining a given
package
•Modules defining identically-named packages do not interfere
with each other.

22. requires transitive
module java.sql {
requires transitive java.logging;
requires transitive java.xml;
exports java.sql;
exports javax.sql;
exports javax.transaction.xa;
}

23. Implied readability
com.example.myapp
com.example.lib
java.sql
java.xml
java.base
org.apache.commons.io
java.logging

24. Strong encapsulation
If two types App and Util are defined in different modules,
and Util is public, then code in App can access Util iff:
1. App’s module requires (i.e. reads) Util’s module, and
2. Util’s module exports Util’s package.
public is no longer public!

25. Migrating to modular code
• An existing classpath app running on Java 8 will continue to run on Java 9, so
long as it only uses standard, non-deprecated Java SE APIs.
• Code that does not belong to a defined module, belongs to the unnamed
module.

26. The unnamed module
• Contains types that exist on the classpath
• Reads (i.e. depends) all other modules, including platform modules
• Exports all packages, ...
• A explicit named module cannot read the unnamed module

27. Bottom-up migration
com.example.app
com.example.orm
com.example.utils
java.sql java.base java.logging

28. Bottom-up migration
com.example.app
com.example.orm
java.sql java.base java.logging
com.example.utils

29. Bottom-up migration
com.example.app
java.sql java.base java.logging
com.example.utils
com.example.orm

30. Bottom-up migration
java.sql java.base java.logging
com.example.utils
com.example.orm
com.example.app

31. DEMO

32. Top-down migration
com.example.app
com.example.orm
com.example.utils
java.sql java.base java.logging

33. Top-down migration
java.sql java.base java.logging
com.example.utils
com.example.orm
com.example.app
Automatic modules

34. Automatic modules
• Its name is derived from Automatic-Module-Name in MANIFEST.MF, or from
the JAR file name
• Non-modular JAR that gets added on the module path
• Exports all its packages
• Reads all other modules
• Reads the unnamed module

35. DEMO