JDK 9 –给圣诞老人的信？

众所周知，冬天（尤其是圣诞节前的时间）是做梦的合适时机，希望有一个梦想似乎可以触摸的时刻。当孩子们和大人在纸上或在对圣诞老人的虚构或真实信件中写下自己的梦想的那一刻，希望他们的梦想将成为现实。这很引人注目，因为甚至在12月的第一天，OpenJDK背后的人们在发布更新的JEP列表时也表达了对Java的愿望。等一下，不要激动，只是还没有......因为我们知道苦涩，他们将有可能成为现实的地方在2016年年初或至少是这样的计划，历史向我们展示了什么坚持一个计划手段。

当然，上述列表中包含JEP，并不意味着最终版本将包含JEP，因为JEP 流程图清楚地说明了这一点，但是为了避免寒冬，我们将遍历列表并提供一个JEP。简要说明每个项目的预期目的是什么。

免责声明： JEP列表是一个移动的目标，因为本文发布后，该列表至少更改了一次。

那些幸运的不是那么好的人，似乎圣诞老人惩罚了您，并且您很高兴使用Java的进程api，并且当然满足了他的限制。在JDK 7中进行了更改之后，当前的JEP进一步改进了该API，并使我们能够：

获取当前Java虚拟机的pid（或等效值）以及使用现有API创建的进程的pid
获取/设置当前Java虚拟机的进程名称以及使用现有API创建的进程（如果可能）
枚举系统上的Java虚拟机和进程。有关每个进程的信息可能包括其pid，名称，状态以及可能的资源使用情况
处理流程树，特别是一些破坏流程树的方法
处理数百个子流程，也许复用输出或错误流，以避免为每个子流程创建线程

我不了解您，但我肯定可以找到至少两个可以充分利用其中某些功能的场景，所以请稍等。

前几天，我有幸与Peter Lawrey一起参加性能研讨会，而Java性能调优的经验法则之一是：应用程序的并发最少，性能更高。有了这项改进，性能调整的规则可能需要找到另一个经验法则，因为使用此JEP实施的目标是在Java中使用监视器的延迟。更准确地说，目标是：

字段重新排序和缓存行对齐
加快PlatformEvent::unpark()
快速Java监视器输入操作
快速Java监视器退出操作
快速Java监视器notify / notifyAll操作
自适应旋转改进和SPARC上的SpinPause

标题说明了一切。如果您使用的是企业应用程序，则必须至少处理一次或两次gc日志，并且我想在查看信息量及其显示方式时至少要引起注意（如果不是全部）。好吧，如果您足够“幸运”，那么您可能会在JVM版本之间进行迁移，然后当您意识到为先前版本构建的解析器遇到了与当前版本有关的问题时，肯定希望/需要再引起两个注意。 JVM日志记录。我想我可以继续说明为什么不好，但是让我们集中精力进行改进，因此希望在下一个发行版中，我们有理由抱怨说，情况会好一些。

gc日志记录似乎试图与我们可能也会使用的其他日志记录框架（如log4j）保持一致。因此，从所记录的信息的严重性（错误，警告，信息，调试，跟踪）的角度来看，它将在不同级别上工作，其性能目标是错误和警告不会对生产环境产生任何性能影响，适合生产环境的信息，而调试和跟踪没有任何性能要求。默认日志行如下所示：

[gc][info][6.456s] Old collection complete

为了确保灵活性，日志记录机制将可通过JVM参数进行调整，目的是对它们采用统一的方法。为了向后兼容，将尽可能将现有的JVM标志映射到新标志。

To be as suitable as possible for realtime applications, the logging can be manipulated through jcmd command or MBeans.

该JEP唯一可能也是最大的缺点是，它的目标只是提供日志记录机制，并不一定意味着日志也会有所改进。为了拥有美丽的原木，我们梦想也许我们需要再等一会。

您可能知道，Java平台使用JIT编译器来确保编写的应用程序的最佳运行。现有的两个直接称为C1和C2的编译器分别对应于client（-client选项）和服务器端应用程序（-server选项）。该JEP的明确目标是提高这些编译器的可管理性：

对JVM编译器（C1和C2）的细粒度和方法上下文相关的控制。
在运行时更改JVM编译器控制选项的能力。
性能不会下降。

JVM的性能似乎是将来的Java版本的目标，因为当前的JEP旨在优化代码缓存。目标是：

单独的非方法，概要文件和非概要文件代码
由于专门的迭代器跳过了非方法代码，因此扫描时间更短
缩短一些编译密集型基准测试的执行时间
更好地控制JVM内存占用
减少高度优化的代码的碎片
改进代码局部性，因为很可能会及时关闭相同类型的代码
- 更好的iTLB和iCache行为
为将来的扩展奠定基础
- 改进了对异构代码的管理；

从我的角度来看，前两个已声明的目标非常令人兴奋，有了这两个目标，只需跳过非方法区域，即在整个JVM运行时中应该存在的区域，可以大大提高代码缓存的扫描时间。

这种改进的出现并不令人惊讶，但对我而言，它并没有在JDK中出现更令人惊讶，因为JSON取代XML成为了Web的“通用语言”，不仅适用于响应式JS前端-end，但也用于构造NoSQL数据库中的数据。该JEP声明的目标是：

JSON RFC7159的解析和生成。
功能满足使用JSON的Java开发人员的需求。
解析API，允许选择解析令牌流，事件（包括文档层次结构上下文）流或JSON文档和数据流的不可变树表示视图。
紧凑的概要文件和Java ME的有用API子集。
使用构建器风格的API进行不可变的价值树构造。
JSON数据流输出和JSON“文字”的生成器样式API。
转换器API，将现有的值树作为输入并生成新的值树作为结果。

同样，其目的是与JSR 353保持一致。即使未来的JSON与现有的库相比功能有限，它也具有集成和使用JDK 8中新添加的功能（如流和lambda）的竞争优势。

sjavac是已经著名的javac的包装，该包装旨在在编译大型项目时提高性能。与当前阶段一样，该项目存在稳定性和可移植性问题，主要目标是修复给定的问题，并使其有可能成为JDK项目的默认构建工具。扩展的目标是使该工具可用于除JDK以外的项目，并可能与现有工具链集成。

朝着项目拼图的实施方向迈出的第一步，旨在将源代码重新组织为模块，从而增强了用于模块构建和尊重模块边界的构建工具。

该JEP的目标是促进使大型代码库清除掉棉绒警告。使用@SuppressWarnings批注无法抑制导入时的过时警告，这与在代码中使用过时的成员不同。在像JDK这样的大型代码库中，通常必须在一段时间内支持不赞成使用的功能，并且如果故意和禁止使用不赞成使用的构造，则仅导入不赞成使用的构造并不能作为警告消息的依据。

由于JDK 9的午餐日期是2016年初，因此该JEP非常适合一年中的那个时候以及相应的琐事：Spring大扫除。它的主要目标是至少在平台的基本软件包下，在javac的lint选项（-Xlint：all）下进行干净的编译。

从JDK 7开始，ProjectCoin的目标是在Java语言中引入一些语法糖，以在成熟的平台上引入一些新功能。即使它没有对语言的性能进行任何改进，它也提高了代码的可读性，因此，在我看来，它为软件项目的最重要资产之一带来了加分，在我看来，这是一个更具可读性的代码库。

该JEP针对四个变化：

在私有实例方法上允许@SafeVargs 。
允许在try-with-resources语句中将有效最终变量用作资源。
如果推断类型的参数类型是可表示的，则允许菱形具有内部类。
从Java SE 8开始，从合法标识符名称集中删除下划线。

随着Java 8发行版中弃用的JVM标志的删除，Spring清理工作继续进行，因此，在9发行版中，不再支持以下选项：

DefNew + CMS       : -XX:-UseParNewGC -XX:+UseConcMarkSweepGC
ParNew + SerialOld : -XX:+UseParNewGCParNew + iCMS      : -XX:+CMSIncrementalMode -XX:+UseConcMarkSweepGC
ParNew + iCMS      : -XincgcDefNew + iCMS      : -XX:+CMSIncrementalMode -XX:+UseConcMarkSweepGC -XX:-UseParNewGC
CMS foreground     : -XX:+UseCMSCompactAtFullCollection
CMS foreground     : -XX:+CMSFullGCsBeforeCompactionCMS foreground     : -XX:+UseCMSCollectionPassing

该JEP旨在Fix javac来正确接受和拒绝程序，而不管import语句的顺序如何，并extends和implements子句。

已经设计了越来越多的使用UDP传输的应用层协议，特别是诸如会话初始协议（SIP）和电子游戏协议之类的协议使安全性问题比以往任何时候都高，尤其是因为TLS仅可用于诸如TCP之类的可靠协议上。当前的JEP打算通过定义用于数据报传输层安全性（DTLS）版本1.0（ RFC 4347 ）和1.2（ RFC 6347 ）的API来填补这一空白。

作为JEP 201的后续步骤，旨在重组JDK和运行时环境以容纳模块并提高性能，安全性和可维护性。定义一个新的URI方案，以命名运行时映像中存储的模块，类和资源，而无需透露映像的内部结构或格式。根据需要修改现有规格以适应这些更改。

随着HTML标准版本达到版本5，JDK的javadoc页面也需要跟上步伐，因此需要从HTML 4.01升级。

在JRE启动时，删除请求的功能（通过使用-version :），该功能不是正在启动的JRE的JRE版本。删除将逐步进行：版本9中将发出警告，而Java 10可能会引发错误。

这是为JDK 9准备的增强功能列表的当前形式，老实说，当我初次查看它时，我有些沮丧，但是在阅读了更多内容后，我感到非常兴奋，因为Java似乎尚未开始进行另一次冒险，他们需要获得的所有帮助。因此，如果您想参与进来（请做！），java advent系列的后续博客文章将向您介绍如何参与。想象一下它就像环上的同伴船，但是冒险的目标是建造Java而不破坏环……弗罗多先生可能是谁？