Java9模組化是什麼
Java9新特性中的模組化到底是什麼
Java9中的一個重大特性是增加了一種新型的程式設計元件 - 模組。
官方對模組的定義為：一個被命名的，程式碼和資料的自描述集合。（ the module， which is a named， self-describing collection of code and data）。
這個在Java7的時候就已經被提出，但由於其複雜性，不斷跳票Java7、Java8，直到Java9才姍姍來遲的模組化，到底是什麼，在實際coding中又有什麼用呢？
我們主要從以下三個方面來分析：
What
模組化是什麼
How
模組化怎麼用
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，提供了高效能的非同步非阻塞呼叫支援。
本文為個人學習整理，如有描述錯誤或者對相關內容感興趣，歡迎評論或私信交流，一起討論、共同進步。
