Modules in Java 9 (JPMS Basics)

Java 9 introduced a powerful feature called the Java Platform Module System (JPMS), also known as Project Jigsaw.

This update brought a major change in how Java applications are designed, organized, and managed. It helps developers write code that is more clean, secure, and scalable.

What is JPMS (Java Module System)?

The Java Module System (JPMS) is a way to organize Java code into modules instead of only using packages.

A module is a collection of related packages and resources grouped together with clearly defined dependencies.

👉 In simple words: A module works like a small independent unit (mini-application) inside a larger application. It gives you control over:

• What your module exposes to other modules (exports)
• What your module depends on (requires)

This makes your code more organized, secure, and easier to maintain.

Why Java Introduced Modules?

Before Java 9, Java applications mainly used JAR files to manage code and dependencies.

However, this approach had several limitations:

• No strong encapsulation (everything was mostly accessible)
• Difficult to manage dependencies properly
• Limited control over security

Common Problems:

• Classpath conflicts (also known as JAR hell)
• No clear boundaries between different parts of the application
• Difficult to maintain large applications

Solution: JPMS

To solve these problems, Java 9 introduced the Java Platform Module System (JPMS).

JPMS helps improve how applications are structured and managed by:

• Improving encapsulation (only required parts are exposed)
• Managing dependencies clearly
• Increasing application security
• Enhancing performance

Key Concepts of JPMS

The Java Module System is based on a few core concepts that help in organizing and managing applications efficiently.

1. Module

A module in Java is defined using a special file called:

module-info.java

👉 This file is used to define:

• The module name
• Its dependencies (what it requires)
• The packages it exports (what is accessible to others)

2. module-info.java (Heart of JPMS)

The module-info.java file is the core of the Java Module System. It defines how a module works and interacts with other modules.

module com.example.myapp {
    requires java.sql;
    exports com.example.service;
}

Explanation:

• module → defines the module name
• requires → specifies dependencies (which modules are needed)
• exports → makes a package accessible to other modules

3. requires Keyword

The requires keyword is used to declare a dependency on another module.

requires java.sql;

👉 This means the current module depends on the java.sql module.

4. exports Keyword

The exports keyword is used to make a package accessible to other modules.

exports com.example.service;

👉 Only the exported packages are visible and accessible outside the module.

5. Encapsulation

In the Java Platform Module System (JPMS), encapsulation is strongly enforced at the module level.

• Only the exported packages are accessible to other modules
• All other internal packages remain hidden and cannot be accessed

👉 This provides strong encapsulation at the JVM level, improving security and modular design.

Module Structure

MyApp/
 └── src/
     └── com.example.myapp/
         ├── module-info.java
         ├── com/example/service/
         │     └── UserService.java
         └── com/example/model/
               └── User.java

Explanation

• module-info.java → defines the module configuration
• requires → adds dependency on another module
• exports → makes selected packages available to other modules
• Internal packages (like model) stay hidden unless exported

Difference Between exports vs opens

Both exports and opens are used to control access in Java modules, but they work differently.

exports

exports com.example.service;

• Provides compile-time and runtime access
• Used for normal communication between modules

opens

opens com.example.model;

• Provides runtime-only access (mainly for reflection)
• Commonly used by frameworks like Hibernate and Spring

Key Difference

Types of Modules

Java 9 (JPMS) supports three types of modules: Named Modules, Unnamed Modules, and Automatic Modules.

1. Named Modules

Named modules are the modules that are explicitly defined by the developer using a module-info.java file.

• They have a clear module name
• Dependencies are fully controlled and declared
• Used in modern Java applications (Java 9+)

Example of Named Module

module-info.java

module com.example.myapp {
    requires java.sql;
    exports com.example.service;
}

2. Unnamed Modules

Unnamed modules are traditional Java programs that run using the classpath, without using the module system.

• Old classpath-based code
• Do not use module-info.java
• All classes are accessible without module restrictions

👉 Basically, these are legacy Java applications.

Example

java -cp MyApp.jar com.example.Main

3. Automatic Modules

Automatic modules are created when you place existing JAR files into the module path.

• JAR files are automatically treated as modules
• No module-info.java is required
• Useful for using old libraries in JPMS

Example

java --module-path libs --module com.example.myapp/com.example.Main

👉 Suppose you add:

libs/guava-32.0.jar

Then Java automatically treats it as a module, even without module-info.java.

Difference Between Module Path vs Classpath

Both classpath and module path are used to locate and load Java classes, but they work in very different ways.

Example: Simple Module

This is a basic example showing how a module is created, how a class is defined inside it, and how it is used in another module.

Step 1: Create Module

In this step, we define a module using module-info.java and specify what packages it will expose to other modules.

module com.app.calculator {
    exports com.app.calc;
}

Step 2: Create Class

In this step, we create a Java class inside the exported package. This class contains the actual business logic.

package com.app.calc;

public class Add {

    public int sum(int a, int b) {
        return a + b;
    }
}

Step 3: Use in Another Module

In this step, another module uses the calculator module by declaring it as a dependency using requires.

module com.app.main {
    requires com.app.calculator;
}

ServiceLoader API (uses / provides)

The ServiceLoader API in Java modules is used to achieve loose coupling between modules. It helps one module use a service without knowing its exact implementation.

Example: Using Service

module com.app.user {
    uses com.app.service.PaymentService;
}

• This module declares that it uses a service interface (PaymentService)
• It does not know the implementation details

Example: Providing Service

module com.app.provider {
    provides com.app.service.PaymentService
    with com.app.impl.UPIPayment;
}

• This module provides the implementation of the service
• UPIPayment is the actual implementation class

Reflection Access in JPMS

In JPMS, reflection access is restricted by default to improve security and encapsulation.

This means classes inside a module cannot be accessed freely using reflection unless explicitly allowed.

Allowing Reflection Access

To allow reflection, we use the opens keyword.

opens com.example.model;

This allows runtime (reflection) access to the package

Opening to Specific Module

We can also open a package to a specific module only:

opens com.example.model to spring.core;

This allows reflection access only for the specified module

Advantages of JPMS

• Strong encapsulation – Internal code is hidden and only required parts are exposed
• Better security – Reduces unwanted access to sensitive code
• Clear dependencies – All module dependencies are explicitly defined
• Avoids classpath issues – Eliminates problems like “JAR hell”
• Improved maintainability – Easier to manage large applications
• Better performance – Optimized loading of only required modules

Limitations of JPMS

• Learning curve for beginners – Understanding modules, module-info.java, and dependencies takes time
• Migration is complex – Converting large existing applications to modules can be difficult
• Not required for small applications – For simple projects, JPMS may feel unnecessary and overcomplicated

Important Keywords Summary

These are the most important keywords used in the Java Module System (JPMS) and their purposes.

Real-World Use Cases

The Java Platform Module System (JPMS) is mainly used in large and complex applications where better structure and dependency management are needed.

• Large enterprise applications – Helps manage big codebases in a structured way
• Microservices architecture – Supports modular and independent services
• Modular libraries – Allows building reusable and well-structured libraries
• Scalable systems – Makes it easier to scale and maintain applications

When to Use Modules?

Java Modules (JPMS) are most useful when your application needs better structure and dependency management.

• Large applications – Helps manage big and complex codebases
• Complex dependencies – Makes dependency handling clear and controlled
• Reusable libraries – Useful for creating modular and reusable components

When NOT to Use Modules?

In some cases, using JPMS may add unnecessary complexity.

• Small projects – Not needed for simple applications
• Simple apps – Adds extra structure without benefit
• Quick prototypes – Slows down development process

Conclusion

The Java Module System (JPMS) is a powerful feature introduced in Java 9 that brings better structure, security, and scalability to Java applications.

It helps developers build applications in a more organized and controlled way.

• Improves code organization
• Provides strong access control (encapsulation)
• Manages dependencies in a clear way

👉 While JPMS may not be required for small projects, it is very important for modern enterprise-level Java applications where scalability and maintainability matter.