拼圖項目的動機和目标

幾周前，我寫了一篇關于Jigsaw項目如何破壞現有代碼的文章 。 那麼，我們能得到什麼回報呢？ 讓我們看一下項目解決的痛點及其在Java 9中解決問題的目标。

系列

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

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

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

總覽

在檢視項目目标之前，我們将首先介紹激發建立拼圖項目的痛點。

主要資源包括JSR 376和Java 9和Beyond ，由Mark Reinhold（Oracle Java平台組首席架構師）在EclipseCon 2015上發表。

痛點

Jigsaw項目旨在解決幾個難題。

JAR /類路徑地獄

很多人都寫過有關類路徑地獄和JAR地獄的文章 ，是以無需重複。

當運作庫解決依賴關系的方式與開發人員認為的不同時，就會出現此問題。 例如，這可能導緻運作版本錯誤的庫。 尋找造成這種情況的原因可能非常令人不快（是以，樂觀的說法）。

發生這種情況的原因是Java運作時加載類的方式。 該機制很脆弱（例如，取決于順序），可能很複雜（例如，具有多個嵌套的類加載器），是以很容易出錯。 此外，運作時無法分析需要哪些類，是以隻有在運作時才能發現未實作的依賴項。

通常也不可能滿足對同一庫的不同版本的依賴。

跨封裝的弱封裝

Java的可見性修飾符非常适合在同一包中的類之間實作封裝。 但是跨程式包邊界隻有一種可見性： public 。

由于類加載器将所有已加載的程式包折疊成一個大泥球，是以所有其他類都可以看到所有公共類。 是以，無法建立在整個JAR中可見但不在其外部可見的功能。

這使得正确地子產品化系統非常困難。 如果子產品的不同部分需要某些功能（例如，系統的庫或子項目），但在子產品外部不可見，則實作此功能的唯一方法是将它們全部放入一個包中（是以，能見度可以使用）。 這有效地删除了代碼以前可能擁有的任何結構。

手動安全

跨軟體包邊界的弱封裝的直接後果是，與安全相關的功能将暴露給在同一環境中運作的所有代碼。 這意味着惡意代碼可以通路關鍵功能，進而可能使其繞過安全措施。

從Java 1.1開始，這是由黑客阻止的：在與安全性相關的代碼中的每個代碼路徑上均調用

java.lang.SecurityManager.checkPackageAccess

并檢查是否允許通路。 或更準确地說：應該在每個這樣的路徑上調用它。 忘記這些調用會導緻一些漏洞，這些漏洞過去困擾着Java。

啟動表現

Java運作時加載目前所需的類并及時編譯常用的類需要一段時間。

原因之一是，類加載對類路徑上的所有JAR執行線性掃描。 同樣，識别所有出現的特定批注要求檢查類路徑上的所有類。

剛性Java運作時

在Java 8之前，無法安裝JRE的子集。 所有Java安裝都支援例如XML，SQL和Swing，許多用例根本不需要。

盡管這與中型計算裝置（例如桌上型電腦或筆記本電腦）無關緊要，但對于最小的裝置（例如路由器，電視盒，汽車以及所有其他使用Java的角落和縫隙），顯然很重要。 在目前的容器化趨勢下，它也可能與伺服器相關，減少圖像的占用空間将降低成本。

Java 8帶來了緊湊的概要檔案 ，這些概要檔案定義了Java SE的三個子集。 他們減輕了問題，但沒有解決。 緊湊的概要檔案是固定的，是以無法滿足部分JRE目前和将來的所有需求。

釋出時間由裡卡多Cuppini下， CC-BY-NC-ND 2.0 。

拼圖項目的目标

拼圖項目旨在通過引入一種語言級機制來子產品化大型系統來解決上述問題。 此機制将在JDK本身上使用，開發人員也可以在自己的項目上使用。 （下一篇文章中有關計劃功能的更多詳細資訊。）

重要的是要注意，并非所有目标對于JDK和我們的開發人員都同樣重要。 許多代碼與JDK更為相關，并且大多數代碼不會對日常編碼産生巨大影響（與lambda表達式或預設方法不同 ）。 他們仍将改變大型項目的開發和部署方式。

可靠的配置

各個子產品将聲明其對其他子產品的依賴性。 運作時将能夠在編譯時，建構時和啟動時分析這些依賴關系，是以可以因缺少或沖突的依賴關系而快速失敗。

強封裝

Project Jigsaw的主要目标之一是使子產品僅導出特定的軟體包。 所有其他軟體包均為該子產品專用。

子產品專用的類應該與專用字段專用于類的方式完全相同。 換句話說，子產品邊界不僅應确定類和接口的可見性，還應确定其可通路性。

馬克·雷因霍爾德（Mark Reinhold）–拼圖項目：将全局視為焦點

子產品對庫或其他子產品的依賴關系也可以保持私有。 是以，兩個子產品可以使用同一庫的不同版本，每個子產品都将其自身依賴于該代碼。 然後，運作時将版本分開，進而防止沖突。

改進的安全性和可維護性

子產品内部API的強大封裝可以大大提高安全性和可維護性。

這将對安全性有所幫助，因為關鍵代碼現在已從不需要使用它的代碼中有效地隐藏了。 由于子產品的公共API可以更容易地保持較小的尺寸，是以使維護更加容易。

随意使用Java SE Platform實作内部的API既有安全風險，又有維護負擔。 提議的規範提供的強大封裝将允許實作Java SE平台的元件阻止對其内部API的通路。

JSR 376

性能提升

通過明确使用代碼的範圍，可以更有效地利用現有的優化技術。

當已知某個類隻能引用其他一些特定元件中的類，而不引用運作時加載的任何類時，許多提前進行的全程式優化技術可能更有效。

JSR 376

也可以為有關現有注釋的代碼編制索引，以便無需進行完整的類路徑掃描就可以找到此類。

可擴充平台

通過将JDK子產品化，使用者可以選擇自己需要的功能，并建立僅由所需子產品組成的自己的JRE。 這将保持Java作為小型裝置和容器的關鍵角色的地位。

拟議的規範将允許Java SE平台及其實作分解為一組元件，開發人員可以将它們組裝成僅包含應用程式實際所需功能的自定義配置。

JSR 376

反射

我們已經看到Java在加載類的方式，在龐大且不斷增長的，剛性的運作時中封裝方面存在一些問題。 Jigsaw項目旨在通過引入一種子產品化機制來解決此問題，該機制将應用于JDK，并且也将對使用者可用。

它保證了可靠的配置和強大的封裝，可以使JAR / classpath成為過去。 它可以用來提高安全性，可維護性和性能。 最後重要的一點是，這将允許使用者建立特定于他們自己的Java運作時。

本系列的下一篇文章将讨論Project Jigsaw将帶給Java 9的功能。敬請期待！

翻譯自: https://www.javacodegeeks.com/2015/06/motivation-and-goals-of-project-jigsaw.html