成都的网站建设公司,公司做网站一般多少钱,电子商务网站建设意义,嘉兴优化网站费用jdk 9和jdk8几天前宣布JDK 9是Feature Complete#xff01; 进行切割的许多“功能”是附加功能#xff0c;但有些是移除功能。 这篇文章介绍了一些从OpenJDK和/或Oracle JDK with Java 9中删除的项目。 JEP 220 #xff08;“模块化运行时图像”#xff09;的一部分是删除… jdk 9和jdk8 几天前宣布JDK 9是Feature Complete 进行切割的许多“功能”是附加功能但有些是移除功能。 这篇文章介绍了一些从OpenJDK和/或Oracle JDK with 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这些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。 Java DB包含在JDK中。” 从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工具”。 删除jhat的动机在JDK-8059039中进行了解释“ jhat是在JDK 6中基于java.net HAT项目添加的 。 jhat是一个实验性的不受支持的且过时的工具。 优质的堆可视化器和分析器现已问世多年。” jhat替代jhat包括Eclipse Memory Analyzer ToolMAT和VisualVM 。 OpenJDK JDK 9 Outreach文档中也记录了此删除操作并且在文章OpenJDK 9没有HPROF和jhat的生活中提到了此删除操作 。 Java虚拟机工具接口hprof代理 JEP 240从JDK中删除了JVM TI hprof代理。 关于HPROF的JDK 8技术说明堆/ CPU分析工具指出我已经强调了 “ Java 2平台标准版J2SE 始终提供一个简单的命令行分析工具称为HPROF用于堆和cpu分析。 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.htmljdk 9和jdk8
