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)
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
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
...
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!
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.
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
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
