馬克·雷因霍爾德（Mark Reinhold）最近提議延遲Java 9，以花更多的時間來完成Jigsaw項目，這是即將發布的版本的主要功能。 雖然這個決定肯定會使Java的厄運論者重回舞臺，但我個人感到很放心，并認為這是一個很好且必要的決定。 Java 9功能完成的里程碑當前設置為12月10日 ，禁止在該日期之后引入新功能 。 但是， 從 Jigsaw項目的早期訪問版本來看，Java的模塊系統似乎尚未為該開發階段做好準備。

在最新的Java發布周期中，項目Jigsaw的延遲已成為一種習慣 。 一定不能將其誤解為無能，而只能作為一種指示，說明向Java引入模塊有多困難，而Java目前對于真正的模塊化來說是陌生的。 最初，Java的模塊系統是在2008年提出的，以包含在Java 7中。但是直到今天，拼圖的實現始終比預期的要困難得多。 在幾次停職甚至是暫時的放棄之后，Java的管理員肯定會承受最終成功的壓力。 很高興看到這種壓力并沒有促使Java團隊急于發布。

在本文中，我嘗試總結一下Jigsaw項目的狀態，并在Jigsaw郵件列表中進行了公開討論 。 我寫這篇文章是對當前討論的貢獻，希望有更多的人參與正在進行的開發過程。 我無意淡化Oracle的辛勤工作。 我在明確聲明這一點是為了避免在隱藏sun.misc.Unsafe之后對拼圖進行了相當激動的討論之后進行的誤解。

模塊化反射

究竟是什么使Jigsaw項目如此困難？ 如今，可見性修飾符是封裝類范圍的最接近的近似值。 Package-privacy可以用作其包裝類型的不完美保留。 但是對于跨越多個程序包的內部API的更復雜的應用程序，可見性修飾符不足，因此需要真正的模塊。 使用項目Jigsaw，可以真正封裝類，這使它們對于某些代碼不可用，即使這些類被聲明為公共類也是如此。 但是，基于所有類在運行時始終可用的假設下構建的Java程序可能需要進行根本性的更改。

對于最終用戶應用程序的開發人員而言，此更改的根本性可能不如Java庫和框架的維護人員。 庫通常在編譯過程中不知道其用戶代碼。 為了克服此限制，庫可以回退到使用反射。 這樣，用于依賴項注入的容器（例如Spring）可以實例化應用程序的bean實例，而框架在編譯時并不知道bean類型。 為了實例化此類對象，容器只需將其工作延遲到運行時，直到它掃描應用程序的類路徑并發現現在可見的bean類型。 對于這些類型中的任何一種，框架都將定位一個構造函數，該構造函數在解析所有注入的依賴項后會進行反射性調用。

一長串Java框架使用與反射配對的運行時發現。 但是在模塊化環境中，如果不解決模塊邊界問題，就無法再運行以前的運行時分辨率。 使用項目Jigsaw，Java運行時斷言每個模塊僅訪問在訪問模塊的描述符中聲明為依賴項的模塊。 此外，導入的模塊必須將相關的類導出到其訪問器。 依賴項注入容器的模塊化版本無法將任何用戶模塊聲明為依賴項，因此禁止進行反射訪問。 實例化未導入的類時，這將導致運行時錯誤。

為了克服此限制，Jigsaw項目添加了一個新的API，該API允許在運行時包含其他模塊依賴性。 使用此API并添加所有用戶模塊后，模塊化的依賴項注入容器現在可以繼續實例化在編譯時不知道的bean類型。

但是這個新的API真的可以解決問題嗎？ 從純功能的角度來看，此附加API允許遷移庫以保留其功能，即使將其重新包裝為模塊也是如此。 但是不幸的是，模塊邊界的運行時強制要求在使用大多數反射代碼之前先進行儀式舞蹈。 在調用方法之前，調用者需要始終確保相應的模塊已經是調用者的依賴項。 如果框架忘記添加此檢查，則會在編譯期間拋出運行時錯誤而沒有發現任何機會。

由于許多庫和框架都過度使用了反射，因此可訪問性的這種變化不太可能改善運行時封裝。 即使安全管理器會限制框架添加運行時模塊依賴項，強制執行此類邊界也可能會破壞大多數現有應用程序。 更現實的是，大多數違反模塊邊界的行為并不表示真正的錯誤，而是由代碼遷移不當引起的。 同時，如果大多數框架搶占了對大多數用戶模塊的訪問權限，則運行時限制不可能改善封裝。

當模塊在其自身類型上使用反射時，此要求當然不適用，但是在實踐中這種反射的使用非常少見，可以通過使用多態來代替。 在我眼中，在使用反射時強制執行模塊邊界與它的主要用例相矛盾，并使本來就不容易的反射API更加難以使用。

模塊化資源

除了這個限制，目前還不清楚依賴注入容器將如何發現它應該實例化的類。 在非模塊化應用程序中，框架可以例如期望給定名稱的文件存在于類路徑上。 然后，此文件用作描述如何發現用戶代碼的入口點。 通常通過從類加載器請求命名資源來獲取此文件。 對于項目Jigsaw，當所需的資源也封裝在模塊的邊界內時，這將不再可能。 據我所知，資源封裝的最終狀態尚未完全確定。 但是，當嘗試當前的早期訪問版本時，將無法訪問外部模塊的資源。

當然，拼圖項目的當前草案中也解決了這個問題。 為了克服模塊邊界，已授予Java 預先存在的ServiceLoader類超能力。 為了使特定的類可用于其他模塊，模塊描述符提供了一種特殊的語法，該語法允許通過模塊邊界泄漏某些類。 應用此語法，框架模塊聲明它提供了某種服務。 然后，用戶庫聲明框架可以訪問該服務的實現。 在運行時，框架模塊使用服務加載器API查找其服務的任何實現。 這可以用作在運行時發現其他模塊的方式，并且可以替代資源發現。

乍看之下，這種解決方案似乎很優雅，但我仍然對此提議表示懷疑。 服務加載器API的使用非常簡單，但同時，其功能也非常有限。 此外，很少有人對其自己的代碼進行修改，這可以視為其范圍有限的指標。 不幸的是，只有時間才能證明此API是否能夠充分容納所有用例。 同時，可以將單個Java類與Java運行時緊密地聯系在一起，從而幾乎不可能棄用和替換服務加載程序API。 在Java的歷史背景下，已經講述了許多看起來不錯但又變味的想法，我發現創建這樣一個神奇的中心很容易成為現實，它很容易成為實現瓶頸。

最后，還不清楚如何在模塊化應用程序中公開資源。 盡管Jigsaw不會破壞任何二進制兼容性，但從以前總是返回值的ClassLoader::getResource調用返回null可能只是將應用程序埋在成堆的null指針異常下。 例如，代碼操縱工具需要一種方法來定位類文件，這些類文件現在已經封裝起來，這至少會阻礙它們的采用過程。

可選依賴項

服務加載器API無法容納的另一個用例是可選依賴項的聲明。 在許多情況下，可選的依賴項不被認為是一種好習慣，但實際上，如果可以將依賴項組合成大量排列，它們提供了一種便捷的方法。

例如，如果特定的依賴項可用，則庫可能能夠提供更好的性能。 否則，它將退回到另一個不太理想的選擇。 為了使用可選的依賴關系，需要庫根據其特定的API進行編譯。 但是，如果此API在運行時不可用，則庫需要確保永不執行可選代碼，并退回到可用的默認值。 這樣的可選依賴關系無法在模塊化環境中表達，在模塊化環境中，即使從未使用過依賴關系，在應用程序啟動時都會驗證任何聲明的模塊依賴關系。

可選依賴項的一個特殊用例是可選注釋包。 今天，Java運行時將注釋視為可選的元數據。 這意味著，如果類加載器無法定位注釋的類型，則Java運行時將僅忽略所關注的注釋，而不是拋出NoClassDefFoundError 。 例如， FindBugs應用程序提供了一個注釋包，用于在用戶發現相關代碼為假陽性后抑制潛在的錯誤。 在應用程序的常規運行時期間，不需要特定于FindBugs的注釋，因此它們不包含在應用程序包中。 但是，在運行FindBugs時，該實用程序會顯式添加注釋包，以使注釋變為可見。 在拼圖項目中，這不再可能。 僅當模塊聲明對注釋包的依賴性時，注釋類型才可用。 如果以后在運行時缺少此依賴項，則盡管注釋不相關，也會引發錯誤。

非模塊化

當然，不將框架捆綁為Java 9中的模塊是避免所有討論的限制的最簡單方法。 Java運行時將任何未模塊化的jar文件視為類加載器的所謂未命名模塊的一部分 。 這個未命名的模塊定義了對正在運行的應用程序中存在的所有其他模塊的隱式依賴性，并將其所有程序包導出到任何其他模塊。 當混合模塊化和非模塊化代碼時，這可以作為備用。 由于未命名模塊的隱式導入和導出，所有未遷移的代碼應繼續像以前一樣運行。

盡管這種選擇退出可能是沉重反射框架的最佳解決方案，但是緩慢采用項目Jigsaw的確也違反了模塊系統的目的。 由于時間的缺乏是大多數開源項目的主要限制，因此很可能會出現這種結果。 此外，許多開源開發人員都必須將其庫編譯為舊版Java。 由于模塊化和非模塊化代碼的運行時行為不同，因此框架需要維護兩個分支，以便能夠使用Java 9 API遍歷模塊化捆綁包中的模塊邊界。 許多開源開發人員不太可能花時間來使用這種混合解決方案。

代碼檢測

在Java中，反射方法訪問不是庫與未知用戶代碼進行交互的唯一方法。 使用工具API ，可以重新定義類以包含其他方法調用。 例如，這通常用于實現方法級別的安全性或收集代碼指標。

在檢測代碼時，通常會在類加載器加載Java類的類文件之前立即對其進行更改。 由于通常在緊接類加載之前應用類轉換，因此當前無法預先更改模塊圖，因為未加載的類的模塊是未知的。 如果檢測代碼在首次使用之前無法訪問已加載的類，則可能會導致無法解決的沖突無法解決。

摘要

軟件估算很困難，我們所有人都傾向于低估應用程序的復雜性。 Jigsaw項目對Java應用程序的運行時行為進行了根本性的更改，將發布推遲到徹底評估所有可能性是非常合理的。 當前，有太多未解決的問題，這是延遲發布日期的不錯選擇。

我希望模塊邊界根本不由運行時強制執行，而是保留為編譯器構造。 盡管存在一些缺陷，Java平臺已經實現了泛型類型的編譯時擦除，并且該解決方案運行良好。 如果沒有運行時強制實施，則在JVM上采用動態語言的模塊也將是可選的，因為與Java中相同的模塊化形式可能沒有意義。 最后，我覺得當前嚴格的運行時封裝形式試圖解決一個不存在的問題。 在使用Java多年之后，我很少遇到無意間使用內部API引起嚴重問題的情況。 相比之下，我記得在很多情況下濫用本應為私有的API可以解決我無法解決的問題。 同時，Jigsaw仍無法解決Java中缺少模塊的其他癥狀（通常稱為jar hell） ，Jigsaw不能區分模塊的不同版本。

最后，我認為向后兼容性的適用范圍超出了二進制級別。 實際上，二進制不兼容通常比行為更改更容易處理。 在這種情況下，Java多年來成就斐然。 因此，方法合同應與二進制兼容性一樣受尊重。 盡管項目Jigsaw從技術上講不會通過提供未命名的模塊來破壞方法契約，但是模塊化基于其綁定對代碼行為進行了微妙的更改。 我認為，這將使經驗豐富的Java開發人員和新手都感到困惑，并導致重新出現運行時錯誤。

這就是為什么我發現強制運行時模塊邊界的價格與其提供的好處相比過高的原因。 OSGi是一個具有版本控制功能的運行時模塊系統，適用于確實需要模塊化的用戶。 作為一個很大的好處，OSGi在虛擬機之上實現，因此不會影響VM行為。 另外，我認為Jigsaw可以為庫提供一種規范的方式，使其在有道理的情況下選擇退出運行時約束，例如對于大量反射的庫。

翻譯自: https://www.javacodegeeks.com/2015/12/project-jigsaw-incomplete-puzzle.html

總結

以上是生活随笔為你收集整理的拼图项目：一个不完整的难题的全部內容，希望文章能夠幫你解決所遇到的問題。

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