A basic introduction into Jigsaw and the impact on Java-Application startup time as well as the footprint

Years ago monolithic software often seems widespread while in recent years developers have focused on structuring their application architecture into technical components to achieve maintainable self-contained software units. Since Java offered no direct support to separate different parts of software functionality, using Maven modules in combination with naming conventions has been a quite widespread approach.

Introduction to Jigsaw

With Jigsaw a general module system was introduced into Java 9 which provides the native module formation within the language itself. A module consists of a list of packages and is defined using a Java file called module-info.java which specifies access properties of the module.
Basically the module-info contains the name of the module and a package access description using the commands requires, exports and opens.
Requires describes exported packages from other modules that can be used inside the module.
Exports and opens describe the access level of packages defined inside the module. By default, packages are not accessible outside the parent module.

Jigsaw distinguishes between exports (public fields and methods of exported packages are available for other modules) and opens (also private fields and methods are accessible for other modules).

Access	Compile-Time	Runtime	Runtime (deep reflection)
exports package	allowed	allowed	not allowed
opens package	not allowed	allowed	allowed

To restrict exported or opened modules for specific packages Jigsaw provides a to-operator as you can see in the code example below.

module java11demo {
    requires spring.boot;
    requires spring.boot.autoconfigure;
    requires spring.core;
    requires spring.web;
    requires spring.context;
    requires spring.beans;
    requires com.fasterxml.classmate;

    // public available api
    exports dev.guschlbauer.java11demo.api;

    // public available restricted to specific packages
    exports dev.guschlbauer.java11demo to spring.beans, spring.context;
    exports dev.guschlbauer.java11demo.service1.service to spring.beans;
    exports dev.guschlbauer.java11demo.service2.service to spring.beans;

    // deep reflection access
    opens dev.guschlbauer.java11demo to spring.core;
    opens dev.guschlbauer.java11demo.api to spring.core;
}

Impact of Jigsaw on footprint and startup time of Spring Boot Java-Applications

The modularization of Jigsaw has also a positive impact on the footprint of the environment as well as the startup time.
To provide some data I developed a minimal Demo Spring Boot application and measured the startup time. The diagram below compares five application starts with and without the Jigsaw modularization approach. With Jigsaw enabled an average startup time optimization of 29% could be found.

The memory footprint of the Jigsaw enabled version of the simple Demo-Application is also smaller than without Jigsaw. Since the Demo-Application is basically an empty Spring Boot application containing three Java classes the optimization is quite small. I guess the footprint, as well as the startup-time optimization, has a higher impact on large-scale applications.