Java9新特性中的模塊化到底是什麼

Java9中的一個重大特性是增加了一種新型的程式設計組件 - 模塊。

官方對模塊的定義為：一個被命名的，代碼和數據的自描述集合。（ the module, which is a named, self-describing collection of code and data）。

這個在Java7的時候就已經被提出，但由於其複雜性，不斷跳票Java7、Java8，直到Java9才姍姍來遲的模塊化，到底是什麼，在實際coding中又有什麼用呢？

我們主要從以下三個方面來分析：

1. What 模塊化是什麼

2. How 模塊化怎麼用

3. Why 為什麼要用模塊化

模塊化是什麼？

模塊是Java9中新增的一個組件，可以簡單理解為是package的上級容器，是多個package的集合，一個jar可以有多個module，一個module可以有多個package。從代碼結構上看，jar > module > package > class, interface。

Java9的模塊通過requires和exports關鍵字，對自身所依賴（requires）的模塊和自身暴露（exports）出去的內容（package）進行了聲明。本模塊只能使用其他模塊暴露（exports）出來的內容（package），其他模塊也只能使用本模塊暴露（exports）出去的內容（package）。

Java9的模塊化和Maven的區別在於Maven管理的是整個jar的依賴，關註的是整體。而模塊化管理的是這個jar中的模塊需要對外暴露的內容和對外依賴的模塊，關註的是細節。maven的依賴是將整個jar都給你了，哪怕你僅僅只需要其中的一個類。模塊化的依賴則是更細粒度的package的管理，你只能使用你依賴的模塊下被暴露出來的package。

那麼，模塊化怎麼用呢？

我們搭建一個簡單的modular-demo項目，分為modular-common，modular-persistent，modular-service，modular-web 4個子項目。

4個子項目的定位為：

modular-common：通用層，主要提供常量類、工具類、枚舉類等通用代碼。

modular-persistent：持久層，主要提供資料庫領域實體domain類，數據操作介面dao。

modular-service：service層，主要提供業務邏輯處理的service及其實現類。

modular-web：web層，主要對外提供api介面，視圖渲染，輸入輸出數據處理等功能。

4個子項目的maven依賴關係為：

modular-persistent依賴modular-common

modular-service依賴modular-persistent

modular-web依賴modular-service

每個項目的代碼大致如下：

與傳統Maven項目不同的是，每個子項目下麵都有著自己的module-info.java，裡面聲明瞭項目中的模塊暴露出去的包和需要依賴的模塊。

註意：我們提到的模塊均是指Java9中的模塊，不是指maven中的模塊，maven中的模塊是指可以構建為一個jar或者war的項目，本質是一個項目，所以我們用子項目來表示maven中的模塊。每個子項目可以有多個模塊，demo中每個子項目只包含了一個模塊，但不代表只能有一個模塊。

common模塊的module-info.java

module modular.demo.common {
    // 聲明自己對外暴露的包名
    exports com.hanmc.example.modulardemo.common;
}

module 後面的modular.demo.common聲明瞭本模塊的模塊名，是本模塊的唯一標識，其它模塊可以通過這個標識來聲明對這個模塊的依賴。

exports com.hanmc.example.modulardemo.common 聲明瞭本模塊暴露出去的package，如果所有package都沒有暴露，那麼其他模塊即使依賴了這個模塊，也依然無法使用此模塊中的代碼。

persistent模塊的module-info.java

module modular.demo.persistent {
    exports com.hanmc.example.modulardemo.persistent.domain;
    exports com.hanmc.example.modulardemo.persistent.dao;
​
    //聲明需要依賴的模塊
    requires modular.demo.common;
    requires mybatis.plus;
    requires mybatis.plus.core;
    requires mybatis.plus.annotation;
}

將domain和dao兩個package暴露出去，同時聲明瞭對modular-common和mybatis-plus框架中的模塊的依賴。

service模塊的module-info.java

module modular.demo.service {
    exports com.hanmc.example.modulardemo.service;
    exports com.hanmc.example.modulardemo.service.impl;
    
    requires modular.demo.persistent;
    requires spring.context;
    requires spring.beans;
}

將service這個package暴露出去，同時聲明瞭對modular-persistent和spring框架中模塊的依賴。

註意：modular-service模塊只暴露了com.hanmc.example.modulardemo.service這個package，並沒有暴露com.hanmc.example.modulardemo.service.impl這個包，所以外部是無法使用service介面的實現類的，只能通過service介面來調用，對於使用者來說隱藏了具體的實現。

web模塊的module-info.java

module modular.demo.web {
    requires spring.web;
    requires spring.beans;
    requires spring.boot;
​
    requires modular.demo.service;
    requires modular.demo.persistent;
    requires modular.demo.common;
    requires org.mybatis.spring;
    requires spring.boot.autoconfigure;
​
    //聲明com.hanmc.example.modulardemo包對spring開放，允許spring在運行期間通過反射機制訪問其代碼
    opens com.hanmc.example.modulardemo to spring.core, spring.beans, spring.boot, spring.context, spring.web;
}

聲明瞭對spring框架和modular-common、modular-persistent、modular-service的模塊的依賴。同時將com.hanmc.example.modulardemo的package開放給spring的模塊使用，以便spring在啟動時通過反射機制訪問項目中的代碼來初始化容器。

註意： exports和opens的區別在於，exports導出的包可以在編譯和runtime期間訪問其public成員。opens聲明的包，則還可以在運行期間通過反射來訪問其public和private成員。

為什麼要用模塊化

那麼，為什麼要用模塊化呢，使用模塊化有什麼好處呢？看起來代碼的編寫反而更為複雜了！

顯式管理依賴：

每個模塊需要顯式聲明自己需暴露的包，而自己所依賴的和自己內部使用的包，則不會暴露，也不會被外部引用到。這種機制徹底的杜絕了Java9以前Jar包依賴買一送一堆的場景，大大的減少Jar包衝突的情況。

場景：比如我的項目中本身已經依賴了hibernate-validator用來做參數校驗，在後續的開發中由於加解密需要又引入了一個提供了加解密api的第三方的jar，這個第三方jar也依賴了另外一個版本hibernate-validator，那麼在項目中就存在了兩個不同版本的hibernate-validator，這個時候就會出現jar包衝突。這個時候模塊化就可以完美解決這個問題，這個第三方加解密的jar可以在module-info.java中只exports出本身加解密功能的部分package，而不會exports出這個jar本身所依賴的其他jar包。

強封裝性：

模塊顯式的選擇向其他模塊只暴露需要的類或介面，而完美的隱藏了內部實現的細節及其他內部成員，實現了真正的封裝。

場景：比如下圖module-common中的枚舉類DefaultResponseEnum，定義了系統內置的幾種預設響應碼，因為被定義在了inner包中，而inner包又沒有被聲明exports，所以這個枚舉類只能在module-common內部使用，避免了被其他模塊直接使用。

安全性：

顯式依賴管理及強封裝性，大大的減少了程式運行時不必要模塊的載入，減少了Java運行期間的被攻擊面。代碼真正意義上可以按照作者的設計思路進行公開和隱藏，限制了反射的濫用，更好的保護了那些不建議被外部直接使用或過時的內部類。

規範性：

顯示的聲明暴露的內容，可以讓第三方庫的開發者更好的管理自己的內部實現邏輯和內部類。第三方庫作者可以更輕鬆的管理自己的內部類的訪問許可權和反射調用許可權，避免了出現sun.misc.BASE64Encoder這些內部類在已經被官方聲明瞭過時和不建議使用的前提下，仍有大量的開發者去隨意使用的情況。因為在Java9之前，JDK開發者只能建議，而無法實現強制約束。

場景：比如我們提倡的面向介面編程，要求在controller中只能註入service層的介面，而不能直接註入其實現類，但是這個要求只是個規範，無法強制約束，Java9以前，我們仍然可以在直接註入service層的實現類，代碼仍然可以照常運行，只是沒那麼規範而已。但是在Java9以後，我們可以在service的模塊中只exports出介面，這樣controller就無法直接註入實現類，在編譯期就會報錯，實現了強約束。

自定義最小運行時映像：

Java因為其向後相容的原則，不會輕易對其內容進行刪除，包含的陳舊過時的技術也越來越多，導致JDK變得越來越臃腫。而Java9的顯示依賴管理使得載入最小所需模塊成為了可能，我們可以選擇只載入必須的JDK模塊，拋棄如java.awt, javax.swing, java.applet等這些用不到的模塊。這種機制，大大的減少了運行Java環境所需要的記憶體資源，在對於嵌入式系統開發或其他硬體資源受限的場景下的開發非常有用。

孵化器模塊的支持：

Java9中，引入了孵化器模塊，使用了固定的首碼jdk. incubator。孵化器模塊是一種提供實驗API的機制，相當於是beta版，其中的內容在後續的版本中可能會被改動或刪除。這個機制的存在，可以讓開發者在明確的知道其不穩定性的同時，如果感興趣的話，可以嘗試提前接觸和使用這些實驗性的功能，使得這個新功能可以在真實環境中不斷打磨完善。

場景：如Java9中提供的jdk. incubator.httpclient模塊，提供了一個全新的HttpClient API，並且在Java11中孵化為正式模式 java.net.http，提供了高性能的非同步非阻塞調用支持。

本文為個人學習整理，如有描述錯誤或者對相關內容感興趣，歡迎評論或私信交流，一起討論、共同進步。