JDK 9是某些功能的终结

几天前宣布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