幾天前宣布JDK 9是Feature Complete！ 進行剪切的許多“功能”都是添加項，但有些是刪除項。 這篇文章介紹了從OpenJDK和/或Oracle的JDK Java 9中刪除的一些項目。

JEP 220 （“模塊化運行時圖像”）的一部分是刪除了Java認可標準覆蓋機制 （“意味著可以將實現認可標準或獨立技術的更高版本的類和接口合并到Java平臺中”）和刪除了支持可選包的擴展機制 （“允許Java虛擬機（VM）使用可選擴展的類，其方式與VM使用Java平臺中的類的方式幾乎相同）”。 可升級模塊旨在替代JDK 9中認可的標準替代機制。關于擴展機制，JEP 220指出：“擴展機制是在1998年發布的JDK 1.2中引入的，但是在現代，我們幾乎沒有證據使用。” Erik Costlow的計劃安全刪除未充分使用的“認可擴展”目錄提供了更多有關這些刪除以及如何檢測它們是否會影響特定Java應用程序的背景。

rt.jar和tools.jar

JEP 220還刪除了眾所周知且經常引用的JAR rt.jar和tools.jar 。 JEP 220解釋說：“以前存儲在lib/rt.jar ， lib/tools.jar ， lib/dt.jar和其他各種內部jar文件中的類和資源文件現在將以特定于實現的更有效格式存儲lib目錄中的文件。 這些文件的格式將不指定，如有更改，恕不另行通知。” 有關刪除這些JAR的其他詳細信息以及這些刪除的預期效果，可以在Java 9中找到，它們完全改變了JDK目錄的布局并刪除了tools.jar ， Java 9和Jigsaw如何破壞您的代碼以及為JDK 9做準備 。 沒有人認為這是廣泛宣傳 ，這些API的目的不是外用，但“一些流行的庫使用不規范，不穩定，不支持的API是JDK的內部實現細節，而且從來沒有在外部使用。”

“大多數”內部API（但不是

編寫JEP 260 （“封裝大多數內部API”）是為了“在[ JDK 9 ]中默認使大多數JDK內部API無法訪問，但是保留一些關鍵的，廣泛使用的內部API，直到所有或大多數支持的替代品都存在為止。功能。” Mark Reinhold的消息“ 在JDK 9中封裝內部API”（sun.misc.Unsafe等）詳細描述了這樣做的動機。 在消除內部 （和臭名昭著 ）API sun.misc.Unsafe 引起軒然大波之后，這種方法是一種折衷方案。 JEP 260文檔詳細討論了哪些內部API將在JDK 9中保持可訪問性，并解釋說某些內部API將在JDK 9中棄用，并在以后的某個時間完全刪除。 “建議在JDK 9中保持訪問的關鍵內部API”包括sun.misc.Unsafe ， sun.misc.Signal和sun.misc.SignalHandler 。

Java數據庫

Oracle的Don Smith 在JDK 9中推遲到Derby的帖子中寫道：“ Java DB僅僅是Apache Derby開源數據庫的重新命名發行版。 它包含與Apache Derby相同的二進制文件。 從JDK 9開始，不再計劃將其包含在Oracle JDK下載的'db'目錄中。 展望JDK 9的開發人員應計劃出于同一目的獨立獲取和捆綁Apache Derby。” 在撰寫本文時， Oracle Java DB頁面指出：“ Java DB是Oracle支持的Apache Derby開源數據庫發行版。 它通過JDBC和Java EE API支持標準的ANSI / ISO SQL。 JDK中包含Java DB。” 從JDK 9開始將不再是這種情況。

自JDK 8起已棄用垃圾收集器選項

如OpenJDK頁面JDK 9 Outreach的“已刪除”部分和JEP 214中所述 ， JDK 8中不推薦使用的“很少使用”垃圾收集選項組合現在已被完全刪除（這意味著包含這些選項組合將阻止JVM而不是簡單地顯示警告消息）。 以下是要刪除的垃圾收集選項的組合：

DefNew + CMS	-XX:-UseParNewGC -XX:+UseConcMarkSweepGC
ParNew + SerialOld	-XX:+UseParNewGC
ParNew + iCMS	-Xincgc
ParNew + iCMS	-XX:+CMSIncrementalMode -XX:+UseConcMarkSweepGC
DefNew + iCMS	-XX:+CMSIncrementalMode -XX:+UseConcMarkSweepGC -XX:-UseParNewGC
CMS前景	-XX:+UseCMSCompactAtFullCollection
CMS前景	-XX:+CMSFullGCsBeforeCompaction
CMS前景	-XX:+UseCMSCollectionPassing

賈特

JEP 241被稱為“刪除jhat工具”，其簡潔的“摘要”為“刪除過時的jhat工具”。 在JDK-8059039中解釋了刪除jhat的動機，“ jhat是在JDK 6中基于java.net HAT項目添加的 。 jhat是一個實驗性的，不受支持的且過時的工具。 優質的堆可視化器和分析器現已問世多年。” jhat替代jhat包括Eclipse Memory Analyzer Tool（MAT）和VisualVM 。 OpenJDK JDK 9 Outreach文檔中也記錄了此刪除操作，并且在文章OpenJDK 9：沒有HPROF和jhat的生活中提到了此刪除操作 。

Java虛擬機工具接口hprof代理

JEP 240從JDK中刪除了JVM TI hprof代理。 關于HPROF的JDK 8技術說明：堆/ CPU分析工具指出（我已經強調了 ），“ Java 2平臺標準版（J2SE） 始終為堆和cpu分析提供了一個簡單的命令行分析工具HPROF。 HPROF實際上是一個JVM本機代理程序庫，它在JVM啟動時通過命令行選項動態加載，并成為JVM進程的一部分。” 如用于刪除它的JDK-8046661中所述，還有其他一些可用于生成“ hprof格式的堆轉儲”的方法，包括jmap -dump和jcmd <pid> GC.heap_dump 。 JDK 9擴展頁面上也對此進行了引用，并在文章OpenJDK 9：沒有HPROF的生活和jhat中對此進行了討論 。

虛擬機

Oracle的Aurelio Garcia-Ribeyro 在JDK 9和更高版本的Visual VM中寫道：“從JDK 9開始，Visual VM將不包括在Oracle JDK中”，并補充說：“希望將Visual VM與Oracle JDK 9或更高版本一起使用的開發人員。以后可以從Visual VM開源項目站點獲取它。 這似乎與Oracle先前決定將NetBeans捐贈給Apache Software Foundation （VisualVM 基于NetBeans Platform ）有關。 代替刪除的jhat工具和HPROF代理，要使用的主要工具之一也需要單獨下載以與JDK 9一起使用。

AppleScript引擎

AppleScript引擎代碼隨JDK 9一起刪除，并且此刪除記錄在OpenJDK頁面JDK 9 Outreach的“已刪除”部分中。

來自RMI的HTTP代理

RDK的HTTP代理已在JDK 8中棄用，并且已從JDK 9中刪除 。 這在“ JDK 9擴展”頁面上被調用。

java.corba和EE模塊的默認分辨率

JDK 9中仍然可以使用java.corba和其他EE模塊，但是默認情況下它們不再可見 。 六個模塊“默認情況下將不可見”是java.activation ， java.annotations.common ， java.corba （不推薦使用）， java.transaction ， java.xml.bind和java.xml.ws。 JEP 261對此進行了更詳細的描述，并解釋說：“默認情況下，類路徑上的代碼不會解析定義Java EE API或Java EE應用程序主要感興趣的API的模塊。” 它稱此更改為“有意的選擇，如果不是很痛苦的話”，旨在“避免與在某些相同程序包中定義類型的流行庫產生不必要的沖突”，并“使現有應用程序服務器更容易遷移到JDK 9”。

JEP 182的“摘要”（“淘汰javac -source和-target選項的政策”）指出：“為減少javac的維護成本，該JEP定義了-target舊的-source和-target選項的策略。 在JDK 8中，將不贊成使用1.5或更早版本的源或目標，而在JDK 9中，將刪除對1.5或更早版本的源或目標的支持。 在JDK 9及以后的版本中，javac將使用受支持的源和目標選項的“一加三后退”策略。 根據這一政策， javac仍然能夠識別和處理所有以前的JDK的類文件，可以追溯到JDK 1.0.2生成的版??本45.3的類文件，該版本于1996年首次發布。

根據JEP 182中概述的策略，JDK 9通過JDK-8011044 “刪除了對1.5及更早版本的源和目標選項的支持”。 Joe Darcy在交付時描述了此更改，“ javac命令不再支持低于6 / 1.6的-source或-target選項。 但是， javac仍然可以讀取較舊的類文件。 可以將較早版本的源代碼移植到較新的源代碼級別。 為了生成舊版本可用的類文件，可以使用以前版本中的javac 。”

其他拆除

OpenJDK JDK 9擴展頁面的“已刪除”部分簡要引用了我在本文中討論的一些項目，還引用了我在本文中未提及的從JDK 9中刪除的一些項目：

• JEP 231 （“刪除啟動時JRE版本選擇”）：“刪除在JRE啟動時請求不是JRE版本的JRE版本的能力。”
• JDK-8037739 ：“在JDK 9時間范圍內刪除對java.awt.peer和java.awt.dnd.peer包的API引用”
• JDK-8029806 ：“刪除打包程序/解包程序的addPropertyChangeListener和removePropertyListener方法”
• JDK-8029805 ：“刪除LogManager addPropertyChangeListener和removePropertyChangeListener方法”
• JDK-8029904 ：““刪除com.sun.security.auth.callback.DialogCallbackHandler”
• JDK-7067728 ：“從默認的java.policy中刪除stopThread RuntimePermission”
• JDK-8134808 ：“從java.desktop中刪除對序列化小程序的支持”

結論

由于對JDK 所做的更改以支持模塊化（ JEP 200 ），因此許多從JDK 9中刪除的項目也將被刪除。 因為有更好的替代支持，或者因為JDK以前包含的產品現在希望單獨下載，所以其他項目也被刪除。

翻譯自: https://www.javacodegeeks.com/2017/01/jdk-9-end-road-features.html

總結

以上是生活随笔為你收集整理的JDK 9是某些功能的终结的全部內容，希望文章能夠幫你解決所遇到的問題。

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