Java 9 Modules

By
Narendran Solai Sridharan

Key Items

Goals of JPMS
Problems in Module Systems
Modularity Maturity Model
Modular JDK
Module in Java
Working of Module System
Layers
Migration to Java 9

Goals of JPMS

Strong Encapsulation
Reliable Configuration
Scalable Java Platform
Greater Platform Integrity
Improved Performance

Strong Encapsulation:

Until Java 9, all classes in the classpath is visible and accessible to all other classes during Runtime. There is no mechanism by which few classes of module can be isolated and encapsulated.

Encapsulation of private fields and method can be broken with reflection.

The Existing encapsulation is not strong enough at runtime and it is brittle.

Reliable Configuration:

Despite various module systems like OSGi, JBoss Modules offers such isolations, there is no way we could check the validity of the configuration at Compile time.

Say if a module XYZ exports a package in version 1.0 and we did create a dependency of it on another module ABC and in version 2.0 of XYZ module if the package is no more exported, the configuration gets broken. The existing configuration becomes invalid.

We cannot rely on a configuration which may or may not be valid at runtime.

Scalable Java Platform:

JDK itself has be broken down into various modules and we can create JDK platform specific images with only modules which is being used by application there by reducing the scale of our Application we develop.

Greater Platform Integrity:

Post Strong Encapsulation and Reliable Configuration, every module could maintain its privacy. Since this privacy is not possible the consumer of the APIs which we expose also consume few APIs which is not exposed for general use. It creates lot of problems even if we change the "not exposed APIs"

Improved Performance:

Lazy loading of modules and avoid loading of modules which is not used in the main application may not be possible without JPMS.

Problems in Module Systems

OSGI, JBoss Modules, Spring Dynamic Modules are few Modular Development Systems.

We face following problems like,

JAR hell / Classpath hell
1. shadowing
2. version conflict
Issue with Unexpressible & Transitive Dependencies
Complex Class Loading

Module Maturity Models

Current System

JPMS

Modular JDK

Module in Java

Everything is a module in Java 9.

Demo Time!!!

The classpath despite they work, is present only for migration. Once we migrate all our components from classpath to "module path", the classpath is no more required. The classloading will happen from "module path".

Show Audience how to create a simple Module in Java 9.

Show only "exported" packages is accessible.
Show Neither the "Top Package" nor the "Sub Package" is accessible.
Tell what is an SPI - Service Provider Interface.

SPI resembles the bridge pattern.

In bridge pattern both the API Implementation and API Client can be changed independently without affecting the other, while pattern like Strategy can change only the API Implementation. While Strategy is predominently used by Application developers for Dependency Injection (Via programming to an interface), Bridges or Adapters are mostly used by frameworks.

show how to build a simple SPI with public constructor: Ensure that the audience see that the non exported Implementation is made accessible to the consumer of the SPI by Module System and tell them that even via reflection accessing the implementation is not possible.
show how to build a SPI factory with provider method: When binding and loading the SPI implementation, a new object is always created. By providing a SPI factory we can control the object creation for SPI implementation.

Notable Restrictions

Cyclic Dependencies

No Cycles in Dependency is allowed in JPMS

Split Packages

No two modules can have same package either it is exported or not.

No Multi Module Support

We cannot have more than one module in an module artifact, either it is a jar or jmod file.

Working of Module System

Module Path & Module Resolution

All modules should be placed in the Module path. Entire classpath is considered as one single "Unnamed" Module.

Types of Module Resolution

Compile Time Resolution
Run Time Resolution

Types of Modules

Automatic Modules
Unnamed Modules
Open Modules

Other kind of Classification

Aggregator Module
Incubator Modules

Impact on Reflection

Automatic Module

Upgrade an existing Module

Implicit Dependency

module org.wildcraft.eaz {
    exports org.wildcraft.eaz;
}

//daz does not just exports it,
//It also exports eaz
module org.wildcraft.daz {
    exports org.wildcraft.daz;
    requires transitive org.wildcraft.eaz;
}

//By depending on daz,
//caz implicity depends on eaz
module org.wildcraft.caz {
    requires org.wildcraft.daz;
}

Optional Dependency

//gaz requires haz only at compile time
//It also depends on iaz implicitly
module org.wildcraft.gaz {
    requires static org.wildcraft.haz;
}

//haz depends on iaz only at compile time
//it also export iaz
module org.wildcraft.haz {
    exports org.wildcraft.haz;
    requires transitive static org.wildcraft.iaz;
}

module org.wildcraft.iaz {
    exports org.wildcraft.iaz;
}

Versioning Modules

Testing Modules

Layers

Layers holds various modules.

Configuration and multi layers

In each layer one or more classloaders can be created based on Configuration.

Modularity Rail Road Diagram