From Monolithic to Modular Java: A Retrospective and Ongoing Evolution

This chapter is from the book

JVM Performance Engineering: Inside OpenJDK and the HotSpot Java Virtual Machine

Learn More Buy

This chapter is from the book

This chapter is from the book 

JVM Performance Engineering: Inside OpenJDK and the HotSpot Java Virtual Machine

Learn More Buy

Understanding the Java Platform Module System

As just mentioned, the JPMS was a strategic response to the mounting complexity and unwieldiness of the monolithic JDK. The primary goal when developing it was to create a scalable platform that could effectively manage security risks at the API level while enhancing performance. The advent of modularity within the Java ecosystem empowered developers with the flexibility to select and scale modules based on the specific needs of their applications. This transformation allowed Java platform developers to use a more modular layout when managing the Java APIs, thereby fostering a system that was not only more maintainable but also more efficient. A significant advantage of this modular approach is that developers can utilize only those parts of the JDK that are necessary for their applications; this selective usage reduces the size of their applications and improves load times, leading to more efficient and performant applications.

Demystifying Modules

In Java, a module is a cohesive unit comprising packages, resources, and a module descriptor (module-info.java) that provides information about the module. The module serves as a container for these elements. Thus, a module

• Encapsulates its packages: A module can declare which of its packages should be accessible to other modules and which should be hidden. This encapsulation improves code maintainability and security by allowing developers to clearly express their code’s intended usage.

• Expresses dependencies: A module can declare dependencies on other modules, making it clear which modules are required for that module to function correctly. This explicit dependency management simplifies the deployment process and helps developers identify problematic issues early in the development cycle.

• Enforces strong encapsulation: The module system enforces strong encapsulation at both compile time and runtime, making it difficult to break the encapsulation either accidentally or maliciously. This enforcement leads to better security and maintainability.

• Boosts performance: The module system allows the JVM to optimize the loading and execution of code, leading to improved start-up times, lower memory consumption, and faster execution.

The adoption of the module system has greatly improved the Java platform’s maintainability, security, and performance.

Modules Example

Let’s explore the module system by considering two example modules: com.house.brickhouse and com.house.bricks. The com.house.brickhouse module contains two classes, House1 and House2, which calculate the number of bricks needed for houses with different levels. The com.house.bricks module contains a Story class that provides a method to count bricks based on the number of levels. Here’s the directory structure for com.house.brickhouse:

src
── com.house.brickhouse
        ├── com
        │   └── house
        │       └── brickhouse
        │           ├── House1.java
        │           └── House2.java
        └── module-info.java

com.house.brickhouse:
   module-info.java:

module com.house.brickhouse {
    requires com.house.bricks;
    exports com.house.brickhouse;
}

com/house/brickhouse/House1.java:

package com.house.brickhouse;
import com.house.bricks.Story;

public class House1 {
    public static void main(String[] args) {
        System.out.println("My single-level house will need " + Story.count(1) + " bricks");
    }
}

com/house/brickhouse/House2.java:

package com.house.brickhouse;
import com.house.bricks.Story;

public class House2 {
    public static void main(String[] args) {
        System.out.println("My two-level house will need " + Story.count(2) + " bricks");
    }
}

Now let’s look at the directory structure for com.house.bricks:

src
└── com.house.bricks
    ├── com
    │   └── house
    │       └── bricks
    │           └── Story.java
    └── module-info.java

com.house.bricks:
   module-info.java:

module com.house.bricks {
    exports com.house.bricks;
}

com/house/bricks/Story.java:

package com.house.bricks;

public class Story {
    public static int count(int level) {
        return level * 18000;
    }
}

Compilation and Run Details

We compile the com.house.bricks module first:

$ javac -d mods/com.house.bricks src/com.house.bricks/module-info.java src/com.house.bricks/com/
house/bricks/Story.java

Next, we compile the com.house.brickhouse module:

$ javac --module-path mods -d mods/com.house.brickhouse
src/com.house.brickhouse/module-info.java
src/com.house.brickhouse/com/house/brickhouse/House1.java
src/com.house.brickhouse/com/house/brickhouse/House2.java

Now we run the House1 example:

$ java --module-path mods -m com.house.brickhouse/com.house.brickhouse.House1

Output:

My single-level house will need 18000 bricks

Then we run the House2 example:

$ java --module-path mods -m com.house.brickhouse/com.house.brickhouse.House2

Output:

My two-level house will need 36000 bricks

Introducing a New Module

Now, let’s expand our project by introducing a new module that provides various types of bricks. We’ll call this module com.house.bricktypes, and it will include different classes for different types of bricks. Here’s the new directory structure for the com.house.bricktypes module:

src
└── com.house.bricktypes
    ├── com
    │   └── house
    │       └── bricktypes
    │           ├── ClayBrick.java
    │           └── ConcreteBrick.java
    └── module-info.java

com.house.bricktypes:
    module-info.java:

module com.house.bricktypes {
    exports com.house.bricktypes;
}

The ClayBrick.java and ConcreteBrick.java classes will define the properties and methods for their respective brick types.

ClayBrick.java:

package com.house.bricktypes;

public class ClayBrick {
    public static int getBricksPerSquareMeter() {
        return 60;
    }
}

ConcreteBrick.java:

package com.house.bricktypes;

public class ConcreteBrick {
    public static int getBricksPerSquareMeter() {
        return 50;
    }
}

With the new module in place, we need to update our existing modules to make use of these new brick types. Let’s start by updating the module-info.java file in the com.house.brickhouse module:

module com.house.brickhouse {
    requires com.house.bricks;
    requires com.house.bricktypes;
    exports com.house.brickhouse;
}

We modify the House1.java and House2.java files to use the new brick types.

House1.java:

package com.house.brickhouse;
import com.house.bricks.Story;
import com.house.bricktypes.ClayBrick;

public class House1 {
    public static void main(String[] args) {
        int bricksPerSquareMeter = ClayBrick.getBricksPerSquareMeter();
        System.out.println("My single-level house will need "
                            + Story.count(1, bricksPerSquareMeter) + " clay bricks");
    }
}

House2.java:

package com.house.brickhouse;
import com.house.bricks.Story;
import com.house.bricktypes.ConcreteBrick;

public class House2 {
    public static void main(String[] args) {
        int bricksPerSquareMeter = ConcreteBrick.getBricksPerSquareMeter();
        System.out.println("My two-level house will need "
                            + Story.count(2, bricksPerSquareMeter) + " concrete bricks");
    }
}

By making these changes, we’re allowing our House1 and House2 classes to use different types of bricks, which adds more flexibility to our program. Let’s now update the Story.java class in the com.house.bricks module to accept the bricks per square meter:

package com.house.bricks;

public class Story {
    public static int count(int level, int bricksPerSquareMeter) {
        return level * bricksPerSquareMeter * 300;
    }
}

Now that we’ve updated our modules, let’s compile and run them to see the changes in action:

• Create a new mods directory for the com.house.bricktypes module:

  $ mkdir mods/com.house.bricktypes

• Compile the com.house.bricktypes module:

  $ javac -d mods/com.house.bricktypes
  src/com.house.bricktypes/module-info.java
  src/com.house.bricktypes/com/house/bricktypes/*.java

• Recompile the com.house.bricks and com.house.brickhouse modules:

  $ javac --module-path mods -d mods/com.house.bricks
  src/com.house.bricks/module-info.java src/com.house.bricks/com/house/bricks/Story.java
  
  $ javac --module-path mods -d mods/com.house.brickhouse
  src/com.house.brickhouse/module-info.java
  src/com.house.brickhouse/com/house/brickhouse/House1.java
  src/com.house.brickhouse/com/house/brickhouse/House2.java

With these updates, our program is now more versatile and can handle different types of bricks. This is just one example of how the modular system in Java can make our code more flexible and maintainable.

Figure 3.1 Class Diagram to Show the Relationships Between Modules

Let’s now visualize these relationships with a class diagram. Figure 3.1 includes the new module com.house.bricktypes, and the arrows represent “Uses” relationships. House1 uses Story and ClayBrick, whereas House2 uses Story and ConcreteBrick. As a result, instances of House1 and House2 will contain references to instances of Story and either ClayBrick or ConcreteBrick, respectively. They use these references to interact with the methods and attributes of the Story, ClayBrick, and ConcreteBrick classes. Here are more details:

• House1 and House2: These classes represent two different types of houses. Both classes have the following attributes:

  • name: A string representing the name of the house.

  • levels: An integer representing the number of levels in the house.

  • story: An instance of the Story class representing a level of the house.

  • main(String[] args): The entry method for the class, which acts as the initial kick-starter for the application’s execution.

• Story: This class represents a level in a house. It has the following attributes:

  • level: An integer representing the level number.

  • bricksPerSquareMeter: An integer representing the number of bricks per square meter for the level.

  • count(int level, int bricksPerSquareMeter): A method that calculates the total number of bricks required for a given level and bricks per square meter.

• ClayBrick and ConcreteBrick: These classes represent two different types of bricks. Both classes have the following attributes:

  • getBricksPerSquareMeter(): A static method that returns the number of bricks per square meter. This method is called by the houses to obtain the value needed for calculations in the Story class.

Next, let’s look at the use-case diagram of the Brick House Construction system with the House Owner as the actor and Clay Brick and Concrete Brick as the systems (Figure 3.2). This diagram illustrates how the House Owner interacts with the system to calculate the number of bricks required for different types of houses and choose the type of bricks for the construction.

Figure 3.2 Use-Case Diagram of Brick House Construction

Here’s more information on the elements of the use-case diagram:

• House Owner: This is the actor who wants to build a house. The House Owner interacts with the Brick House Construction system in the following ways:

  • Calculate Bricks for House 1: The House Owner uses the system to calculate the number of bricks required to build House 1.

  • Calculate Bricks for House 2: The House Owner uses the system to calculate the number of bricks required to build House 2.

  • Choose Brick Type: The House Owner uses the system to select the type of bricks to be used for the construction.

• Brick House Construction: This system helps the House Owner in the construction process. It provides the following use cases:

  • Calculate Bricks for House 1: This use case calculates the number of bricks required for House 1. It interacts with both the Clay Brick and Concrete Brick systems to get the necessary data.

  • Calculate Bricks for House 2: This use case calculates the number of bricks required for House 2. It also interacts with both the Clay Brick and Concrete Brick systems to get the necessary data.

  • Choose Brick Type: This use case allows the House Owner to choose the type of bricks for the construction.

• Clay Brick and Concrete Brick: These systems provide the data (e.g., size, cost) to the Brick House Construction system that is needed to calculate the number of bricks required for the construction of the houses.