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

系列

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

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

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

總覽

在查看項目目標之前，我們將首先介紹激發(fā)創(chuàng)建拼圖項目的痛點。

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

痛點

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

JAR /類路徑地獄

很多人都寫過有關類路徑地獄和JAR地獄的文章 ，因此無需重復。

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

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

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

跨封裝的弱封裝

Java的可見性修飾符非常適合在同一包中的類之間實現(xiàn)封裝。 但是跨程序包邊界只有一種可見性： public 。

由于類加載器將所有已加載的程序包折疊成一個大泥球，因此所有其他類都可以看到所有公共類。 因此，無法創(chuàng)建在整個JAR中可見但不在其外部可見的功能。

這使得正確地模塊化系統(tǒng)非常困難。 如果模塊的不同部分需要某些功能（例如，系統(tǒng)的庫或子項目），但在模塊外部不可見，則實現(xiàn)此功能的唯一方法是將它們全部放入一個包中（因此，能見度可以使用）。 這有效地刪除了代碼以前可能擁有的任何結構。

手動安全

跨軟件包邊界的弱封裝的直接后果是，與安全相關的功能將暴露給在同一環(huán)境中運行的所有代碼。 這意味著惡意代碼可以訪問關鍵功能，從而可能使其繞過安全措施。

從Java 1.1開始，這是由黑客阻止的：在與安全性相關的代碼中的每個代碼路徑上均調用java.lang.SecurityManager.checkPackageAccess并檢查是否允許訪問。 或更準確地說：應該在每個這樣的路徑上調用它。 忘記這些調用會導致一些漏洞，這些漏洞過去困擾著Java。

啟動表現(xiàn)

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

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

剛性Java運行時

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

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

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

發(fā)布時間由里卡多Cuppini下， CC-BY-NC-ND 2.0 。

拼圖項目的目標

拼圖項目旨在通過引入一種語言級機制來模塊化大型系統(tǒng)來解決上述問題。 此機制將在JDK本身上使用，開發(fā)人員也可以在自己的項目上使用。 （下一篇文章中有關計劃功能的更多詳細信息。）

重要的是要注意，并非所有目標對于JDK和我們的開發(fā)人員都同樣重要。 許多代碼與JDK更為相關，并且大多數(shù)代碼不會對日常編碼產(chǎn)生巨大影響（與lambda表達式或默認方法不同 ）。 他們仍將改變大型項目的開發(fā)和部署方式。

可靠的配置

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

強封裝

Project Jigsaw的主要目標之一是使模塊僅導出特定的軟件包。 所有其他軟件包均為該模塊專用。

模塊專用的類應該與專用字段專用于類的方式完全相同。 換句話說，模塊邊界不僅應確定類和接口的可見性，還應確定其可訪問性。

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

模塊對庫或其他模塊的依賴關系也可以保持私有。 因此，兩個模塊可以使用同一庫的不同版本，每個模塊都將其自身依賴于該代碼。 然后，運行時將版本分開，從而防止沖突。

改進的安全性和可維護性

模塊內部API的強大封裝可以大大提高安全性和可維護性。

這將對安全性有所幫助，因為關鍵代碼現(xiàn)在已從不需要使用它的代碼中有效地隱藏了。 由于模塊的公共API可以更容易地保持較小的尺寸，因此使維護更加容易。

隨意使用Java SE Platform實現(xiàn)內部的API既有安全風險，又有維護負擔。 提議的規(guī)范提供的強大封裝將允許實現(xiàn)Java SE平臺的組件阻止對其內部API的訪問。

JSR 376

性能提升

通過明確使用代碼的范圍，可以更有效地利用現(xiàn)有的優(yōu)化技術。

當已知某個類只能引用其他一些特定組件中的類，而不引用運行時加載的任何類時，許多提前進行的全程序優(yōu)化技術可能更有效。

JSR 376

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

可擴展平臺

通過將JDK模塊化，用戶可以選擇自己需要的功能，并創(chuàng)建僅由所需模塊組成的自己的JRE。 這將保持Java作為小型設備和容器的關鍵角色的地位。

擬議的規(guī)范將允許Java SE平臺及其實現(xiàn)分解為一組組件，開發(fā)人員可以將它們組裝成僅包含應用程序實際所需功能的自定義配置。

JSR 376

反射

我們已經(jīng)看到Java在加載類的方式，在龐大且不斷增長的，剛性的運行時中封裝方面存在一些問題。 Jigsaw項目旨在通過引入一種模塊化機制來解決此問題，該機制將應用于JDK，并且也將對用戶可用。

它保證了可靠的配置和強大的封裝，可以使JAR / classpath成為過去。 它可以用來提高安全性，可維護性和性能。 最后重要的一點是，這將允許用戶創(chuàng)建特定于他們自己的Java運行時。

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

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

總結

以上是生活随笔為你收集整理的拼图项目的动机和目标的全部內容，希望文章能夠幫你解決所遇到的問題。

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