Java的模塊系統(tǒng)（Project Jigsaw）從Java 9開(kāi)始引入，旨在解決類(lèi)路徑機(jī)制帶來(lái)的封裝性差、依賴混亂、JDK臃腫等問(wèn)題。 1. 它通過(guò)module-info.java文件定義模塊名稱(chēng)、依賴關(guān)係、導(dǎo)出包和服務(wù)，實(shí)現(xiàn)強(qiáng)封裝和可靠配置；2. java.base作為所有模塊的基礎(chǔ)，內(nèi)部包如jdk.internal.*默認(rèn)不可訪問(wèn)；3. 開(kāi)發(fā)者可使用jlink創(chuàng)建僅包含所需模塊的精簡(jiǎn)運(yùn)行時(shí)，減小部署體積；4. 模塊化提升了安全性、可維護(hù)性和依賴清晰度，但遷移舊項(xiàng)目存在反射受限、拆分包衝突等挑戰(zhàn)；5. 儘管存在學(xué)習(xí)曲線和兼容性問(wèn)題，現(xiàn)代Java開(kāi)發(fā)應(yīng)優(yōu)先採(cǎi)用模塊化設(shè)計(jì)，結(jié)合jlink部署，並避免在生產(chǎn)環(huán)境中使用--add-opens或--illegal-access，以確保系統(tǒng)穩(wěn)健性和安全性。該系統(tǒng)已深刻影響Java應(yīng)用的運(yùn)行方式，成為構(gòu)建可擴(kuò)展、安全、高效系統(tǒng)的必備基礎(chǔ)。

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 maintainable, 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, unclear 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 unclear 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 provides

 // Example: module-info.java
module com.example.myapp {
    requires java.base;
    requires 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 minimal 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

Despite 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 takes 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 become "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 gradual 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, maintainable 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.

以上是Java模塊系統(tǒng)的演變（Project Jigsaw）的詳細(xì)內(nèi)容。更多資訊請(qǐng)關(guān)注PHP中文網(wǎng)其他相關(guān)文章！