因此，拼圖項目...我們已經對此頗為了解，但尚未看到計劃如何兌現其承諾的細節。 這篇文章將精確地做到這一點，并介紹項目的核心概念和功能。

系列

這篇文章是正在進行的有關拼圖項目系列的一部分。 按照推薦的順序（不同于發布順序），它們是：

• 動機和目標
• 核心概念和功能（即將推出）
• 如何破壞您的代碼
• 歷史，結構和當前狀態（即將發生）
• 動手指南（即將在EA版本包含JSR 376的情況下發布 ）

相應的標記列出了有關該主題的更多文章。

總覽

第一部分將介紹Jigsaw項目的核心概念，即模塊。 然后，我們將看到它們將具有哪些功能，以及如何計劃它們與現有代碼和工具進行交互。

本文的主要來源是Jigsaw項目和JSR 376的要求 。 盡管這些文檔基于全面的探索階段，因此非常成熟，但它們仍可能會更改。 接下來的事情是一成不變的。

核心概念

有了Project Jigsaw，Java語言將得到擴展以具有模塊概念。

[模塊]是由代碼和數據組成的自描述程序組件。 模塊必須能夠包含組織成包的Java類和接口，以及動態加載庫形式的本機代碼。 模塊的數據必須能夠包含靜態資源文件和用戶可編輯的配置文件。

Java平臺模塊系統：要求（草案2）

要了解模塊，您可以將每個Apache Commons （例如Collections或IO）， Google Guava或（ cough ） LibFX之類的知名庫都視為模塊。 嗯，取決于作者希望對它們進行拆分的粒度，每個人實際上可能都包含幾個模塊。

對于應用程序也是如此。 它可能是單個整體模塊，但也可能分成多個模塊。 我想說一個項目的規模和凝聚力將是決定該項目可以組成的模塊數量的主要決定因素。 當然，它的實際體系結構和實現是否允許這是另外一個故事。

計劃是模塊將成為開發人員中用來組織代碼的常規工具。

開發人員已經在語言方面考慮了標準種類的程序組件，例如類和接口。 模塊應該只是另一種程序組件，像類和接口一樣，它們應該在程序開發的所有階段都具有含義。

Mark Reinholds –拼圖項目：聚焦全局

然后，可以在開發的所有階段（即在編譯時，構建時，安裝時或運行時）將模塊組合成各種配置。 它們將對像我們這樣的Java用戶可用（在這種情況下有時稱為開發人員模塊 ），但也將用于剖析Java運行時本身（通常稱為平臺模塊 ）。

實際上，這是有關如何將JDK模塊化的當前計劃：

特征

那么模塊如何工作？ 查看計劃中的功能將有助于我們對它們有所了解。

請注意，即使以下各節將介紹許多功能，也不會在所有可用詳細信息中進行討論，也不會完整列出這些功能。 如果您想了解更多信息，可以從方括號中的鏈接開始，或者立即查看Jigsaw項目和JSR 376的完整要求 。

依賴管理

為了解決JAR / classpath的難題 ，Jigsaw Project實現的核心功能之一是依賴管理。

聲明與決議

一個模塊將聲明編譯和運行[ 依賴項 ]所需的其他模塊。 模塊系統將使用它來可傳遞地標識編譯或運行初始一個[ 分辨率 ]所需的所有模塊。

也有可能不依賴于特定模塊而是依賴于一組接口。 然后，模塊系統將嘗試查找實現這些接口并因此滿足依賴項[ services ， binding ]的模塊。

版本控制

將支持版本控制模塊[ 版本控制 ]。 他們將能夠指示自己的版本（只要完全排序即可使用幾乎任何格式），以及對其依賴項的約束。 在任何階段都可以覆蓋這兩條信息。 模塊系統將在每個階段強制配置滿足所有約束。

Project Jigsaw不一定會在單個配置中支持模塊的多個版本 [ 多個版本 ]。 但是，等等，那這如何解決JAR地獄呢？ 好問題。

模塊系統也可能未實現版本選擇。 因此，當我在上面寫道“模塊系統[將]識別編譯或運行所需的所有模塊”時，這是基于每個模塊只有一個版本的假設。 如果有多個，則上游步驟（例如，開發人員，或者更可能是他使用的構建工具）必須進行選擇，并且系統將僅驗證其滿足所有約束[ 版本選擇 ]。

封裝形式

從同一類路徑加載的所有其他代碼將自動提供JAR中的所有公共類和接口。 對于模塊而言，情況將有所不同，在這些模塊中，系統將在所有階段強制執行更強的封裝（無論是否存在安全管理器）。

一個模塊將聲明特定的包，并且僅導出其中包含的類型。 這意味著只有它們將對其他模塊可見并且可訪問。 更嚴格的說，這些類型只會導出到那些明確依賴包含它們的模塊的模塊中[ export ， encapsulation ]。

為了幫助開發人員（尤其是那些模塊化JDK的開發人員）保持較小的導出API界面，將存在其他發布機制。 這將允許一個模塊指定要導出的其他軟件包，但只能導出到一組指定的模塊。 因此，盡管使用“常規”機制，導出模塊將不知道（也不關心）誰訪問了軟件包，但該模塊將允許它限制可能的依賴項集合（ 合格的出口 ）。

模塊也可能會重新導出其依賴的模塊的API（或其部分）。 這將允許在不破壞依賴關系的情況下拆分和合并模塊，因為原始模塊可以繼續存在。 他們將導出與以前完全相同的軟件包，即使它們可能不包含所有代碼[ 重構 ]。 在極端情況下，所謂的聚合器模塊可能根本不包含任何代碼，并且只能作為一組模塊的抽象。 實際上，來自Java 8的緊湊型概要文件就是這樣。

不同的模塊將能夠包含相同名稱的軟件包，甚至允許它們導出它們[ export ， non-interference ]。

Oracle將利用這個機會使所有內部API不可用 。 這將是采用Java 9的最大障礙，但肯定會樹立正確的道路。 首先，因為關鍵代碼現在對攻擊者隱藏了，所以它將大大提高安全性。 它還將使JDK的可維護性大大提高，從長遠來看，這將有回報。

配置，階段和保真度

如前所述，在開發的所有階段，模塊都可以組合成各種配置。 對于平臺模塊而言，這是正確的，可用于創建與完整JRE或JDK，Java 8中引入的緊湊配置文件相同的映像，或僅包含一組指定模塊（及其傳遞依賴項）的任何自定義配置[ JEP 200； 目標 ]。 同樣，開發人員可以使用該機制來組合自己的模塊化應用程序的不同變體。

在編譯時，正在編譯的代碼將僅看到由一組配置的模塊[ 編譯時配置 ]導出的類型。 在構建時，一個新工具（大概稱為JLink ）將允許創建二進制運行時映像，該映像包含特定模塊及其依賴項[ 構建時配置 ]。 在啟動時，可以使圖像看起來像僅包含其模塊的子集[ 啟動時配置 ]。

在每個階段，都可以用較新的版本替換實現認可標準或獨立技術的 模塊 [ 可升級模塊 ]。 這將替代已棄用的認可標準覆蓋機制和擴展機制 。

除非由于特定原因[ 保真 ]不可能，否則模塊系統的所有方面（例如依賴項管理，封裝等）在所有階段都將以相同的方式工作。

所有模塊特定的信息（例如版本，依賴項和包導出）都將在代碼文件中表示，而與IDE和構建工具無關。

性能

整個程序優化技術

在具有強封裝性的模塊系統中，自動推斷將要使用特定代碼段的所有位置要容易得多。 這使得某些程序分析和優化技術更加可行：

快速查找JDK和應用程序類； 早期字節碼驗證； 主動內聯例如lambda表達式和其他標準編譯器優化； 構造特定于JVM的內存映像，該映像可以比類文件更有效地加載； 將方法主體提前編譯為本地代碼； 并刪除未使用的字段，方法和類。

拼圖項目：目標與要求（草案3）

這些被標記為全程序優化技術 ，并且至少有兩種這樣的技術將在Java 9中實現。它還將包含一個工具，該工具可以分析給定的一組模塊，并應用這些優化來創建性能更高的二進制映像。

注解

自動發現帶注釋的類（例如Spring允許）目前需要掃描某些指定包中的所有類。 這通常是在程序啟動時完成的，可能會大大降低它的速度。

模塊將具有一個API，允許調用者使用給定的注釋標識所有類。 一種設想的方法是創建此類的索引，該類的索引將在模塊編譯時創建[ 注解檢測 ]。

發布時間由droetker0912下， CC-BY-NC-SA 2.0 。

與現有概念和工具的集成

診斷工具（例如堆棧跟蹤）將被升級以傳達有關模塊的信息。 此外，它們將被完全集成到反射API中，該反射API可以以與類[ 反射，調試和工具 ]相同的方式來操作它們。 這將包括可以在運行時反映和覆蓋的版本信息[ 反射API中的版本字符串 ， 可覆蓋的版本信息 ]。

該模塊的設計將允許“以最少的麻煩”使用構建工具 [ 構建工具 ]。 模塊的編譯形式可以在類路徑上使用，也可以作為模塊使用，這樣庫開發人員就不必為類路徑和基于模塊的應用程序創建多個工件（ 多模式工件 ）。

還計劃與其他模塊系統（尤其是OSGi）進行互操作 [ 互操作 ]。

即使模塊可以從其他模塊隱藏包，也可以測試其中包含的類和接口[ 白盒測試 ]。

特定于操作系統的包裝

該模塊系統在設計時考慮了軟件包管理器文件格式“ RPM，Debian和Solaris IPS”。 開發人員不僅可以使用現有工具從一組模塊中創建特定于操作系統的軟件包。 這樣的模塊也將能夠調用以相同機制安裝的其他模塊[ 模塊包裝 ]。

開發人員還將能夠將構成應用程序的一組模塊打包到特定于OS的軟件包中，“最終用戶可以按照目標系統的慣常方式來安裝和調用這些軟件包”。 在上面的基礎上，只需打包目標系統上不存在的那些模塊即可[ 應用程序打包 ]。

動態配置

運行中的應用程序可以創建，運行和發布多個隔離的模塊配置[ 動態配置 ]。 這些配置可以包含開發人員和平臺模塊。

這對于諸如IDE，應用程序服務器或Java EE平臺的容器體系結構將很有用。

反射

我們已經看到Project Jigsaw將帶給Java 9的大多數功能。它們都圍繞著模塊的新核心語言概念展開。

在日常編程中，最重要的可能是跨不同階段的依賴關系管理，封裝和配置。 改進的性能始終是一個不錯的選擇。 然后，需要投入大量工作來與現有工具和概念進行合作，例如反射，診斷，構建工具和特定于OS的打包。

等不及要嘗試了？ 我也不行！ 但是，我們必須等到JSR 376進一步問世，然后才能將帶有Project Jigsaw的JDK9或JDK 9的早期訪問版本實際包含模塊系統。 當它最終完成時，您將在這里閱讀有關它的信息。

翻譯自: https://www.javacodegeeks.com/2015/07/the-features-project-jigsaw-brings-to-java-9.html

總結

以上是生活随笔為你收集整理的功能项目拼图将Java 9引入的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。