几天前宣布JDK 9 的功能已经完成！此次削减的许多“功能”都是新增的，但也有一些是删除的。这篇文章着眼于使用 Java 9 从 OpenJDK 和/或 Oracle 的 JDK 中删除的一些项目。
Endorsed-standard Override机制和扩展机制
JEP 220（“模块化运行时映像”）的一部分是删除 Java 认可的标准覆盖机制（“意味着更高版本的类和接口实现了认可的标准或独立技术可以并入 Java 平台”）和删除支持可选包的扩展机制（“允许 Java 虚拟机 (VM) 使用 optional 扩展，与 VM 在 Java 平台中使用类的方式非常相似”）。 可升级模块旨在取代 JDK 9 中认可的标准覆盖机制。关于扩展机制，JEP 220 指出，“扩展机制是在 1998 年发布的 JDK 1.2 中引入的，但在在现代，我们几乎看不到它被使用的证据。” Erik Costlow 的博文规划安全删除未充分使用的‘endorsed extension’目录提供了有关这些删除以及如何检测它们是否会影响特定 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 和 Project Jigsaw 如何破坏您的代码，以及为JDK 9 做准备。没有人会争辩说，这些 API 并非旨在供外部使用，但“一些流行的库使用了非标准、不稳定和不受支持的 API，这些 API 是 JDK 的内部实现细节并且从未打算供外部使用。”
“大多数”内部 API（但不是 sun.misc.Unsafe！）
JEP 260（“封装大多数内部 API”）是为了“使大多数 JDK 的内部 API 默认无法访问 [在 JDK 9 中]，但留下一些关键的、广泛的-使用过的内部 API 可访问，直到所有或大部分功能都存在受支持的替代品。” Mark Reinhold 的消息 Encapsulating internal APIs in JDK 9 (sun.misc.Unsafe, etc.) 详细描述了这样做的动机。这种方法是在因删除内部（和臭名昭著的）API sun.misc.Unsafe 而引起的骚动之后的妥协。 JEP 260 文档详细讨论了哪些内部 API 在 JDK 9 中仍可访问，并解释了一些将在 JDK 9 中弃用并在稍后完全删除。 “建议在 JDK 9 中保持可访问性的关键内部 API”包括 sun.misc.Unsafe、sun.misc.Signal 和 sun.misc.SignalHandler。
数据库
在在 JDK 9 中推迟到 Derby一文中，Oracle 的 Don Smith 写道，“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。 Java DB 包含在 JDK 中。”从 JDK 9 开始，情况将不再如此。
JDK 8 后弃用的垃圾收集器选项
正如 OpenJDK 页面 JDK 9 Outreach 和 JEP 214 的“已删除”部分 中所述，“很少使用的”垃圾收集选项组合 < span>在 JDK 8 中弃用 现在已完全删除（这意味着包含这些选项组合将阻止 JVM 启动，而不是简单地显示警告消息）。以下是要删除的垃圾收集选项的组合：
| DefNew + 内容管理系统 | -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 被称为“Remove the jhat Tool”，其简洁的“Summary”是“Remove the antiquated jhat tool”。 JDK-8059039 中解释了删除 jhat 的动机，“jhat 是在 JDK 6 中添加的，基于 java.net HAT项目。 jhat 是一种实验性、不受支持且已过时的工具。高级堆可视化器和分析器现已面世多年。” jhat 的替代品包括 Eclipse 内存分析器工具 (MAT) 和 VisualVM。此删除也记录在 OpenJDK JDK 9 Outreach 文档 中，并在文章 OpenJDK 9：没有 HPROF 和 jhat 的生活 中提到。
Java 虚拟机工具接口 hprof 代理
JEP 240 从 JDK 中移除了 JVM TI hprof Agent。关于HPROF：堆/CPU 分析工具 的 JDK 8 技术说明（我添加了强调），“Java 2 平台标准版 (J2SE) 具有always 提供了一个名为 HPROF 的简单命令行分析工具，用于堆和 CPU 分析。 HPROF 实际上是一个 JVM 本地代理库，它在 JVM 启动时通过命令行选项动态加载，并成为 JVM 进程的一部分。”如 JDK-8046661 中所述，用于删除它，还有其他替代方法可用于生成“hprof 格式的堆转储”，包括 jmap -dump 和 jcmd
虚拟机
Oracle 的 Aurelio Garcia-Ribeyro 在JDK 9 及更高版本中的 Visual VM 中写道，“从 JDK 9 开始，Oracle JDK 将不再包含 Visual VM”并补充说，“想要使用 Visual VM 的开发人员使用 Oracle JDK 9 或更高版本的 Visual VM 可以从Visual VM 开源项目站点获取。这似乎与 Oracle 早前决定将 NetBeans 捐赠给 Apache 软件基金会有关（VisualVM 基于 NetBeans 平台）。代替已删除的 jhat 工具和 HPROF 代理使用的主要工具之一也需要单独下载以便与 JDK 9 一起使用。
AppleScript 引擎
AppleScript 引擎代码已随 JDK 9 一起删除，此删除记录在 OpenJDK 的“已删除”部分 JDK 9 推广 页。
来自 RMI 的 HTTP 代理
来自 RMI 的 HTTP 代理已在 JDK 8 中被弃用，并且正在从 JDK 9 中删除。这在 JDK 9 Outreach 页面 上被调用。
java.corba 和 EE 模块的默认解析
java.corba 和其他 EE 模块在 JDK 9 中仍然可用，但它们将默认不再可见。 “默认不可见”的六个模块是 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”。
-source 和 -target 支持 Java 1.5
JEP 182（“淘汰 javac -source 和 -target 选项的策略”）的“摘要”指出，“为了降低 javac 的维护成本，这个 JEP 定义了一个淘汰旧的 -source 和 -target 选项的策略。在 JDK 8 中，将弃用 1.5 或更早版本的源或目标，而在 JDK 9 中，将删除对 1.5 或更早版本的源或目标的支持。在 JDK 9 及以后的版本中，javac 将使用支持的源和目标选项的“一+三回”策略。根据这项政策，javac 仍然能够识别和处理所有以前 JDK 的类文件，可以追溯到 1996 年首次发布的 JDK 1.0.2 生成的 45.3 版类文件。”
根据 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：“删除 Packer/Unpacker 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 中的产品现在预计将单独下载。
标签2： Java教程地址：https://www.cundage.com/article/jcg-jdk-9-end-road-features.html
相关阅读
