Introduction to the Java Module System (Project Jigsaw)

The Java platform has evolved from Java 8 to Java 9 and later, introducing the module system (Project Jigsaw) to address large‑application dependency management, improve performance, simplify the JRE, and enhance compatibility and security.

Module definition: A module is a uniquely named, reusable group of related packages, resources (such as images and XML files), and a module descriptor (module‑info.java).

Module descriptor basics: It declares the module name, required modules, exported packages, opened packages, provided services, and used services. Example syntax includes module com.example.mod { requires java.base; exports com.example.api; opens com.example.internal to java.base; provides com.example.spi.Service with com.example.impl.ServiceImpl; } .

Key benefits:

Clear dependency management – the JVM can detect cycles and resolve split packages.

Smaller JRE – jlink can create custom runtimes, reducing JRE size by up to 50%.

Better compatibility and security – explicit exports and opens control visibility.

Higher development efficiency – modular projects are easier to maintain and evolve.

Seven advantages of modularization:

Strong encapsulation

Clear dependency management

Improved performance

Easier construction of large systems

Better security

Reduced application size

Clear module boundaries

Main parameters and commands (Java 9+):

-p – specify module path (similar to -cp ).

-m – specify the main module and class (e.g., -m com.example.mod/com.example.Main ).

--add-exports , --add-opens – grant access to internal APIs.

--add-modules , --add-reads , --patch-modules – fine‑tune module relationships.

Example modules (mod1‑mod4):

mod1 (main module) uses services defined in mod3:

module mod1 {
    requires mod2a;
    requires mod4;
    uses IEventListener;
}

mod2a exports a package and opens another, providing two service implementations:

module mod2a {
    requires transitive mod3;
    exports mod2a.exports;
    opens mod2a.opens;
    provides IEventListener with mod2a.exports.EchoListener,
                                 mod2a.opens.ReflectEchoListener;
}

mod2b provides an SPI implementation without exporting:

module mod2b {
    requires transitive mod3;
    provides IEventListener with mod2b.SpiEchoListener;
}

mod3 defines the SPI interface:

module mod3 {
    exports mod3.exports;
    // internal package not exported
}

mod4 simply exports a public model class:

module mod4 {
    exports mod4;
}

Migration strategies: bottom‑up (gradually modularize libraries, then the application) and top‑down (start from the main application, converting non‑modular jars to automatic modules when necessary). Automatic modules retain all packages and depend on all named modules, allowing a smooth transition.

Best‑practice recommendations: use meaningful reverse‑domain module names, declare explicit dependencies, follow the minimal‑dependency principle, apply versioned requires when appropriate, keep each module focused on a single responsibility, test module interactions, manage the module path correctly, and leverage tools such as jdeps , jlink , and jmod for analysis and custom runtime creation.