JEP 200：模組化JDK
原文連結 譯者：carvendy
JEP 200:模組化JDK
作者 Mark Reinhold
建立 2014/07/22 14:08
更新 2017/03/08 13:58
型別 特性
狀態 整合
域 SE
JSR 376
討論 拼圖的開發在openjdk.java.net
努力 XL
持續時間 XL
優先 l
檢驗人 Alan Bateman, Alex Buckley, Paul Sandoz
支援 Brian Goetz
發行 9
版本 8051618
依賴 JEP 220:模組化執行時映象
JEP 261:模組系統
JEP 201:模組化原始碼
概要
使用Java平臺模組系統，由
目標
劃分JDK裡面一系列的模組並可以在編譯、構建的時候結合在一起，或者執行的時候進入各種各樣的配置裡面，但是沒有限制：
- 配置相應的所有Java SE平臺，所有JRE，和所有JDK。
- 配置相應相等的在每個契約配置項定義在Java SE 8；
- 自定義配置包含了只有明確規定的部分模組和通過這些模組傳遞所需的模組。
這些模組化結構的定義必須在標準模組之間有一個清晰區別，那些明確規定是Java程式社群支配，和模組是具體到JDK。它必須區分模組，模組將被提出包含Java SE平臺的明確規定，從而制定了強制性的每個平臺的實現，從所有其他模組中。
動機
拼圖專案目的是為了設計和實現一個標準模組系統給Java SE 平臺和允許系統到平臺本身和到JDK。它最初的目的是製造實現平臺可以更容易地拓展下至小裝置，提高保護和可維護性，可以提高程式行為和提供開發者更好的工具為了更大的程式開發。
描述
設計原則
模組化結構提出了實現下面的原則：
- 標準模組化，那些明確規定的是由JCP支配，必須有名字並使用“java.”作為開頭。
- 所有其他模組僅僅是JDK的你一部分，和必須有名字並起始為“.jdk”。
- 如果一個模組匯出一個包包含public或protected成員，反過來，參考一種從其他模組，第一個模組必須給予暗示並可讀的給到第二個，通過公共需求。（這確定方法呼叫鏈工作在明顯的方式）
- 一個標準模組可能包含標準和不標準的API包。如果標準模組匯出一份標準API包那麼匯出可能是合格的。如果標準模組匯出了一個標準非標準API包那麼就必須合格。在任何情況下，如果一個標準模組匯出包有質量那麼匯出必須是一些JDK的模組。如果標準模組是一個Java SE模組等，為了提出包含Java SE平臺明確規定，那麼它就必須不能匯出任何不是SE API的包，至少沒有什麼限制的。、
- 一個標準的模組可以依賴前面一個或者多個不標準模組。這不必授予暗指的並可讀地對於任何非標準模組。如果它是Java SE模組那麼它不必授予可讀的對於任何非SE模組。
- 一個不標準模組不必匯出任何標準的API包。一個不標準的模組可能授予暗指的可讀性到一個標準的模組。
一個重要結果就是準則4和準則5是程式碼依賴在Java SE模組上，將只能依賴標準的Java SE型別，因此對於所有Java SE平臺的實現是行動式的。
模組圖
模組化結構JDK可以是虛擬的一個圖：每個模組是一個節點，和這裡有有向邊從一個模組到另外一個如果第一個依賴上面的第二個。所有模組圖有很多邊界更容易地展示；這裡是圖的傳遞性約簡，在這些冗餘的邊界是省略的（點選可以更大）。
附上模組圖的旅遊指南
- 標準的Java SE 模組是橙色的；非SE模組是藍色的。
- 如果一個模組依賴上面其他的，和它授予了暗示可讀的模組，那麼邊界從第一個到第二個是可靠的；因此，邊界是虛線的。
- 在非常底層的java.base模組，包含本質的類例如 java.lang.Object和java.lang.String。基礎模組沒有依賴上面的模組，和每個其他模組依賴上面的基礎模組。基礎模組的邊界是比其他的要輕量。
- 在頂層的java.se.module模組，整合 了所有模組包含了Java SE平臺，匯入模組是Java EE平臺明確規定的。這是一個聚合模組的例子，收集和復出口其他模組的內容但是加入了它自己沒有內容。一個執行時系統配置包含java.se.ee模組將包含Java SE平臺的所有API包。一個模組將提出包含Java SE平臺規範，只是如果，它是一個標準模組可以從java.se.ee模組獲取。
- java.se 聚合模組集合Java SE平臺的部分模組，內容沒有和Java EE重疊。
- java.compact1,java.compact2,和java.compact3 聚合模組實現了Java SE 契約配置。這裡有一個非標準的jdk.compact3模組因為一個compact3 構建的JDK包含一些非標的SE API包，當其他契約配置構建沒執行。
- 其他非標準模組包含除錯和服務工具和API（例如：jdk,jdi,jdk.jcmd和jdk.jconsole）,開發工具（例如：jdk.compiler,jdk.javadoc,和jdk.xml.bind）,和各種各樣服務提供者（例如：jdk.charsets, jdk.scripting.nashorn, jdk.crypto.ec ),這些是製造可獲得其他模組通過存在的java.util.ServiceLoader機制。
- java.smartcardio模組是標準的但是不是Java SE平臺規範的一部分，由此可見它的名字字首是“java.”但是它是藍色的，和it沒有到達java.se模組。
模組圖是有效的，一個新型別的API，它將被明確規定的和進化的等。模組的子圖基於java.se.ee模組，和所有非SE模組，相應邊界移除將被提出包含Java SE 平臺規範；它的進化將在此後被JCP支配。圖的剩餘進化將被未來的JEPs覆蓋。在另一面，如果一個是指定作為平常可用的而它將受到進化的約束管制作為其他APIs。移除一個模組或者當改變它，在原則上，將需要公共公告至少提前在一個主發行版本。
一個表格概述所有模組，包含構建Linux/AMD64足跡，這裡是可用。
開放版本
當前模組圖定義至少有一個知道的缺陷，列表底下。修復版本將在修改內容可能的結果和圖結構。
- java.management模組依賴上面的java.rmi，它自己是非平凡的大小和經常不是重要的在嵌入驅動情節；我們看著移動的java.management.remote.rmi API包在自己的模組裡面。
測試
單元測試和迴歸測試在JDK和jtreg中，繫帶用於執行它們，將增強允許測試被選中的基礎模組，那些它們測試和上面它們的依賴，所以任意的JDK模組配置可以被測試。
最初的增強功能測試將用於檢查模組的配置集合，確認它是有效的模組定義結合成的，每個模組有預期望的內容和輸出預期的API包，和模組有預期依賴關係。
JCK必須被增強地測試模組圖的各個方面，那些變成Java SE平臺規範的一部分。包含SE模組的名字，它們輸出的API包和依賴持有它們，因此SE API包被重新匯出。在在平臺的實現中，JCK必須被增強測試目前SE模組的任意配置。
風險和假設
模組化結構定義在這裡不解決一些重要的用例。如果在JEP實現首次發行中批判用例是不支援的 而我們希望可以它可以在後面的發行中重構模組圖、
Java SE方面的模組圖定義在JEP，注意，被提出最終的Java SE平臺JSR專家組審查程式碼和標準化。審查程式碼可能要求對圖進一步更改。
依賴
JEP是拼圖專案的一部分。其他JEP是：
