Java 9迫在眉睫，它將帶有完整的Project Jigsaw 。 在我從OpenJFX郵件列表的最近討論中得知它可能會破壞現有代碼之前，我并沒有對此給予太多關注。 這對于Java非常不尋常，因此引起了我的興趣。

我閱讀了該項目的JEP和一些相關文章，得出的結論是，這將破壞現有代碼。 是否會受到影響取決于您的項目，但是您可能會受到影響并且可能會受到傷害。

總覽

在粗略介紹了Jigsaw項目的內容之后，我將描述可能發生的重大變化。

我從可用文檔中編譯了該更改列表。 當然不能保證我能抓住一切，并且由于我不熟悉某些概念，因此我可能會誤會某些事實。 買者自負。

如果您發現錯誤或認為某些事情可以變得更清晰或更精確，請發表評論，我很樂意提供您的意見。

拼圖項目

我可能會在某個時候寫一個關于Jigsaw項目的更詳細的描述，但是現在我會很懶惰，只是引用一下：

該項目的主要目標是：

• 使Java SE平臺和JDK更容易地擴展到小型計算設備；
• 總體上提高Java SE平臺實現（特別是JDK）的安全性和可維護性；
• 改善應用程序性能； 和
• 使開發人員更容易為Java SE和EE平臺構建和維護庫和大型應用程序。

為了實現這些目標，我們建議為Java SE平臺設計和實現一個標準模塊系統，并將該系統應用于平臺本身以及JDK。 該模塊系統應具有足夠的功能以模塊化JDK和其他大型遺留代碼庫，但仍可供所有開發人員采用。

拼圖項目現場– 2015年2月11日

如果您想了解更多有關該項目的信息，請查看其站點 ，尤其是目標和要求列表 （當前版本為2014年7月起的草案3 ）。

這里要帶走的主要東西是模塊系統。 從版本9開始，可以將Java代碼（以及JRE / JDK）組織在模塊中， 而不是 JAR文件中。

發布時間由約爾·本·亞伯拉罕在CC-BY-ND 2.0 。

破碼

這聽起來像是內部重構，那么為什么要破壞現有代碼？ 好吧，它并不一定要這樣做，兼容性甚至是項目的核心要求之一（與Java一樣）：

僅使用標準Java SE API以及可能還使用特定于JDK的API的應用程序必須以與今天相同的方式運行[…]。

拼圖項目：目標與要求–草稿3

重要的部分是限定條件“僅標準API”。 有很多方法可以創建應用程序，這些應用程序的某些關鍵細節依賴于未指定或不建議使用的屬性，例如非標準API，未記錄的文件夾結構和JAR文件的內部組織。

因此，讓我們看看潛在的重大變化。 有關更多詳細信息，請確保檢查項目的站點，尤其是JEP 220 ，該站點包含對隨后大部分內容的更精確描述。

內部API變得不可用

使用JAR文件，任何公共類在JVM中的任何位置都是可見的。 這嚴重限制了JDK實現將內部API保持私有狀態的能力。 取而代之的是許多方法都是可訪問的，并且出于各種原因而經常使用它們（例如，為了提高性能或解決Java運行時中的[先前]錯誤； Java FAQ解釋了為什么這樣做可能不是一個好主意 ）。

這隨模塊而改變。 每個模塊都可以明確聲明哪些類型作為其API的一部分可用。 JDK將使用此功能來正確封裝所有內部API，因此將不可用。

事實證明，這可能是與Java 9不兼容的最大原因。由于它會引起編譯錯誤，因此它肯定是最不敏感的。

為了準備Java 9，您可以檢查代碼是否依賴于內部API。 您找到的所有東西都必須以一種或另一種方式替換。 一些變通辦法可能已變得不必要。 其他類可能會進入公共API。 要確定是否存在這種情況，您必須進行研究，甚至可能要在OpenJDK郵件列表中詢問您感興趣的功能。

內部API

那么什么是內部API？ 絕對是所有生活在sun.*東西。 我無法確認com.sun.*所有內容是否也都是私有的-當然有一部分是但不是全部？

可能證明特別有問題的兩個示例是sun.misc.Unsafe和com.sun.javafx.*所有內容。 顯然，前者已在許多項目中用于執行任務和性能關鍵代碼。 根據個人經驗，我可以說后者是正確構建JavaFX控件的關鍵要素（例如，所有ControlsFX都依賴于這些軟件包）。 還需要解決許多錯誤。

考慮將這兩種特殊情況都轉換為公共API（請參閱Unsafe和JavaFX ，盡管有些人寧愿看到Unsafe死于火災 ）。

工具支援

幸運的是，您不必手動找到這些依賴項。 從Java 8開始，JDK包含Java Dependency Analysis Tool jdeps （ 一些內部軟件包的介紹， Windows和unix的官方文檔），它可以列出項目所依賴的所有軟件包。

如果使用-jdkinternals參數運行它，它將輸出項目使用的所有內部API –恰好是Java 9發行之前必須處理的內部API。

JDK和JRE的合并

Project Jigsaw的主要目標是Java平臺的模塊化，以允許靈活地創建運行時映像。 因此，JDK和JRE失去了其獨特的特性，并成為一系列模塊組合中的兩個可能的點。

這意味著這兩個工件將具有相同的結構。 這包括文件夾結構以及任何依賴于該結構的代碼（例如，通過利用JDK文件夾包含子文件夾jre的事實）將無法正常工作。

內部JAR變得不可用

內部JAR（例如lib / rt.jar和lib / tools.jar）將不再可訪問。 它們的內容將以故意未指定且可能更改的格式存儲在特定于實現的文件中。

假設這些文件存在的代碼將停止正常工作。 由于IDE或類似工具嚴重依賴這些文件，因此這也可能導致過渡方面的麻煩。

運行時圖像內容的新URL架構

一些API在運行時將URL返回到類和資源文件（例如ClassLoader.getSystemResource ）。 在Java 9之前，這些是jar URL ，它們具有以下形式：

jar:file:<path-to-jar>!<path-to-file-in-jar>

Jigsaw項目將使用模塊作為代碼文件的容器，并且不再提供各個JAR。 這需要一種新格式，因此此類API會返回jrt URL ：

jrt:/<module-name>/<path-to-file-in-module>

使用此類API返回的實例來訪問文件的代碼（例如，使用URL.getContent ）將像今天一樣繼續工作。 但是，如果它取決于jar URL的結構 （例如，通過手動構造它們或解析它們），它將失敗。

取消認可的標準替代機制

Java API的某些部分被視為獨立技術，并在Java社區流程（例如JAXB ）之外創建。 可能需要獨立于JDK進行更新或使用替代實現。 認可的標準替代機制允許將這些標準的替代版本安裝到JDK中。

此機制在Java 8中已棄用，在Java 9中將被刪除。其替代品是可升級模塊 。

如果您從未聽說過此消息，則可能不使用它。 否則，您可能想驗證您使用的實現是否將成為可升級模塊。

刪除擴展機制

使用擴展機制，自定義API可以提供給JDK上運行的所有應用程序使用，而不必在類路徑上命名它們。

此機制在Java 8中已棄用，在Java 9中將被刪除。一些有用的功能將保留。

如果您從未聽說過此消息，則可能不使用它。 否則，您可能需要檢查JEP 220以獲得詳細信息。

Java 9的準備

這些變化共同給任何大型項目過渡到Java 9帶來了風險。評估和減少它的一種方法可能是“更新高峰”：使用jdeps識別對內部API的依賴性。 修復這些問題之后，請花一些時間來使用Java 9早期訪問版本之一來構建和運行項目。 徹底測試系統的相關部分，以了解可能出現的問題。

通過這種方式收集的信息可以返回到項目，例如，通過將其發布在Jigsaw-Dev郵件列表中 。 引用JEP 220的（幾乎）最后的話：

不可能確定摘要中這些更改的全部影響。 因此，我們必須依靠廣泛的內部測試，尤其是外部測試。 […]如果其中某些更改被證明對開發人員，部署人員或最終用戶而言是無法克服的障礙，那么我們將研究減輕其影響的方法。

反射與監視

我們已經看到Project Jigsaw將模塊化Java運行時。 內部API（軟件包sun.*以及com.sun.* ）將不可用，并且JRE / JDK的內部結構將發生變化，包括文件夾和JAR。 在Java 8中棄用它們之后，認可的標準覆蓋機制和擴展機制將在Java 9中刪除。

如果您想幫助您的朋友和追隨者為Java 9做準備，請確保分享這篇文章。

到目前為止，我們專注于Jigsaw項目的問題方面。 但這不應偏離計劃中的令人振奮的，而且我認為非常積極的性質。 閱讀文檔后，我對即將發布的Java版本的范圍和潛力印象深刻。 盡管對于單個開發人員而言，它可能不像Java 8那樣具有突破性，但對于參與構建和部署的每個人（尤其是大型整體項目）而言，甚至更是如此。

因此，我一定會再次撰寫有關拼圖計劃的文章-然后著重介紹好的方面。 如果您想了解更多信息，請繼續關注。

翻譯自: https://www.javacodegeeks.com/2015/04/how-java-9-and-project-jigsaw-may-break-your-code.html

總結

以上是生活随笔為你收集整理的Java 9和Project Jigsaw如何破坏您的代码的全部內容，希望文章能夠幫你解決所遇到的問題。

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