The Java module system (Project Jigsaw) was introduced in Java 9, aiming to solve the problems of poor encapsulation, confusion in dependency, and JDK bloated caused by the classpath mechanism. 1. It defines module names, dependencies, export packages and services through module-info.java file to achieve strong encapsulation and reliable configuration; 2. java.base is the basis of all modules, and internal packages such as jdk.internal.* are not accessible by default; 3. Developers can use jlink to create a streamlined runtime that contains only required modules, reducing the deployment volume; 4. Modularity improves security, maintainability and dependency clarity, but there are challenges such as limited reflections and split package conflicts in migration old projects; 5. Despite the learning curve and compatibility issues, modern Java development should give priority to modular design, combined with jlink deployment, and avoid using --add-opens or --illegal-access in production environments to ensure system robustness and security. This system has profoundly influenced the operation of Java applications and has become a necessary basis for building scalable, safe and efficient systems.

Java's module system, better known as Project Jigsaw , was a long-awaited addition to the Java platform that fundamentally changed how Java applications are structured, especially starting with Java 9 . Its evolution was driven by the need to scale the JDK and large applications in a more maintained, secure, and performant way. Here's a breakdown of its journey, purpose, and impact.

Why Was Project Jigsaw Needed?

Before Java 9, Java relied on the classpath mechanism to locate and load classes at runtime. While simple, this model had several drawbacks:

• No encapsulation at the package level : All public classes were accessible, even if they weren't meant for external use (eg, internal JDK APIs like sun.misc.Unsafe ).
• "JAR Hell" : Conflicts from duplicate class names across JARs, uncle dependencies, and circular dependencies were common.
• Monolithic JDK : The entire JDK was bundled together—even if an app used only a small part, the whole runtime had to be shipped.
• Poor scalability : Large applications became harder to maintain due to uncle dependency graphs and lack of structure.

Project Jigsaw aimed to solve these by introducing a module system —a way to group packages into named, self-describing modules with explicit dependencies.

Key Components of the Java Module System

The module system introduced several core concepts:

• Module : A named collection of packages with a module-info.java file that declares:
  • The module's name
  • Which packages it exports (makes publicly available)
  • Which other modules it requires
  • Services it uses or provide

 // Example: module-info.java
module com.example.myapp {
    java.base;
    java.logging;
    exports com.example.myapp.api;
}

• java.base module : The foundational module. Every module implicitly depends on it.
• Strong encapsulation : Only exported packages are accessible. Internal packages (eg, jdk.internal.* ) are now truly hidden.
• Reliable configuration : The JVM validates the entire module graph at startup, detecting missing or conflicting modules early.

Evolution and Adoption Timeline

Practical Benefits for Developers

1. Smaller Runtime Images with jlink

You can now build a minimum JRE containing only the modules your app needs:

 jlink --module-path $JAVA_HOME/jmods:myapp.jar \
      --add-modules com.example.myapp \
      --output myruntime

This reduces container sizes and attack surface—ideal for microservices.

2. Improved Security and Maintainability

By restricting access to internal APIs, the module system prevents accidental (or malicious) use of unstable JDK internals.

3. Clearer Dependencies

Modules make dependencies explicit. No more guessing which libraries a component needs.

4. Better Tooling and Diagnostics

Tools like jdeps analyze dependencies and suggest module configurations:

 jdeps --module-path lib/ --require-recursive myapp.jar

Challenges and Criticisms

Although its benefits, adoption hasn't been universal:

• Migration complexity : Large legacy apps using classpath and reflection (eg, OSGi, Spring ClassPathXmlApplicationContext) faced breakage.
• Split packages : Two modules can't export the same package—common in older libraries.
• Reflection restrictions : Code that relied on accessing internal JDK APIs (eg, for performance tricks) now fails unless --add-opens is used.
• Learning curve : Understanding requires , exports , opens , uses , and provides take time.

Modern Usage and Best Practices

Even if you don't write module-info.java files, the module system affects you:

• Unnamed modules : JARs on the classpath becomes "unnamed modules" and can read all named modules—but they export nothing.
• Automatic modules : JARs on the module path with no module-info are treated as modules with implied names and exports.
• Hybrid approach : Many apps still use the classpath, but benefit from strong encapsulation in the JDK.

Best practices :

• Use modules for new projects when possible.
• Prefer jlink for production deployments.
• Avoid --add-opens and --illegal-access in production.
• Keep internal APIs truly internal.

Conclusion

Project Jigsaw wasn't just a feature—it was a platform overhaul . It made Java more modular, secure, and scalable for modern development, especially in cloud-native environments. While adoption has been graduate and sometimes painful, the benefits in reliability, performance, and deployment efficiency are clear.

For developers, understanding the module system is now essential—not just for using the latest Java features, but for building robust, maintained systems.

Basically, if you're shipping Java apps today, the module system is already shaping how your code runs—whether you see it or not.

The above is the detailed content of The Evolution of the Java Module System (Project Jigsaw). For more information, please follow other related articles on the PHP Chinese website!