隐藏类，密封类，文本块，记录和EdDSA：JDK 15具有很大的价值。
正如我最喜欢的表达式之一所说，Java 15中有很多丰富的巧克力美感。新版本（于2020年9月15日发布）包含旨在改进JDK的14个重要更改（JEP）。本文根据JEP中包含的信息提供了新产品的快速概述。
14个JEP可以分为五个组。有关更详细的研究，请参阅每个文档。
新功能会让您屏住呼吸：
- JEP 339：爱德华兹曲线数字签名算法（EdDSA）
- JEP 371：隐藏的类
现有Java SE标准功能的补充：
- JEP 378：文本块
- JEP 377：ZGC垃圾收集器
- JEP 379：雪兰多亚-低暂停垃圾收集器
对旧版Java SE功能的改进：
- JEP 373：对不推荐使用的DatagramSocket API的全面检查
我们期待着新产品：
- JEP 360：密封课程（预览）
- JEP 375：用于instanceof的模式匹配（第二预览）
- JEP 384：条目（第二稿）
- JEP 383：外部存储器访问API（第二孵化器功能）
取消和终止支持：
- JEP 372: Nashorn JavaScript Engine
- JEP 374:
- JEP 381: Solaris SPARC
- JEP 385: RMI
,
爱德华兹曲线数字签名算法（JEP 339）。我将第一个承认爱德华兹曲线数字签名算法（EdDSA）超出了我的加密知识。好的，我一点都不了解。但是，此JEP被设计为EdDSA的独立于平台的实现，其性能要优于现有的C实现ECDSA。
根据JDK文档，EdDSA是一种现代的椭圆曲线签名方案，与JDK中的现有方案相比，具有多个优点。
实施目标：
- 该JEP的主要目的是实现RFC 8032中标准化的签名方案。但是，新方案不能取代ECDSA。
- - EdDSA , ECDSA . , EdDSA, Curve25519 ~126 , , ECDSA, secp256r1 ~128 .
- , . .
现在您比我知道的更多。请继续关注《 Java Magazine》即将解释EdDSA的文章。
隐藏类（JEP 371）是不能由其他类的字节码直接调用的类。它们打算由在运行时动态创建类并通过反射机制间接使用它们的框架使用。动态生成的类可能只需要有限的时间，因此在静态生成的类的生命周期内保留它们会不必要地增加内存占用。
动态生成的类也是不可检测的。按名称查找此类将是有害的，因为它破坏了它们的目的，即它们只是静态生成的类的实现细节。
隐藏类的发布为开发人员停止使用非标准API sun.misc.Unsafe :: defineAnonymousClass奠定了基础。Oracle打算将来删除并删除此类。
现有Java SE标准的补充
来自Amber项目的文本块（ JEP 378）在JDK 13和14的两个初步版本中终于发布了。创建它们的目的是希望开发人员减少在Java中声明和使用多行字符串文字的难度。
文本块会以可预测的方式自动格式化字符串，但是如果这还不够，开发人员可以接管格式化。初步功能的第二个版本引入了两个新的转义序列，用于处理换行符和空格。例如，\ <line-terminator>显式禁止插入换行符。
以前，要打印一长行文本，您必须这样编写：
使用\使代码更易于阅读：
\的转义序列可以防止删除尾随空格。因此，以下文本代表三行，每行正好由五个字符组成（在中间行，对应于绿色，\ s未被使用，因为它已经包含五个字符）。
在ZDK 11中引入了ZGC垃圾收集器（JEP 377）作为实验功能。现在它已获得正式地位。 ZGC是具有NUMA功能的并行可扩展垃圾收集器，具有低垃圾收集延迟（即使在多TB的堆上也小于10毫秒）。经Oracle测试，平均暂停时间少于1毫秒，最大值少于2毫秒。图1比较了Java并行垃圾收集器G1和ZGC，其中ZGC暂停时间增加了10倍。
图1.垃圾收集器暂停时间的比较
但是，对于许多工作负载，G1（仍是默认值）可能比ZGC稍快。同样，对于很小的堆（例如只有几百兆字节的堆），G1也可以更快。因此，建议您对自己的负载运行自己的测试，以查看要使用的垃圾收集器。
重要提示：由于ZGC不再处于试验阶段（包括在Oracle OpenJDK构建和Oracle JDK中），因此您不再需要使用-XX：+ UnlockExperimentalVMOptions来激活它。
雪兰多（JEP 379）是某些OpenJDK构建中可用的垃圾收集器的另一个变体。自JDK 12起一直在试验。现在，与ZGC一样，XX：+不需要UnlockExperimentalVMOptions。
旧版Java SE功能的现代化
重新设计不推荐使用的DatagramSocket API（JEP 373）。考虑一下这基本上是一些侏罗纪代码的重构，因为此JEP替换了Java.net.DatagramSocket和java.net.MulticastSocket API的旧的，难以维护的实现，它们具有易于维护和调试的简单，现代的实现，并且将使用Project Loom虚拟流。
由于有很多使用旧API的代码（自JDK 1.0起），因此过时的实现不会被删除。实际上，如果API重构在回归测试中或在某些情况下导致问题，则新的特定于JDK的系统属性jdk.net.usePlainDatagramSocketImpl将JDK配置为使用不建议使用的实现。
我们期待新产品
密封等级（JEP 360）。在Project Amber中创建的第一个预生产版本。密封的类和接口将其扩展或实现限制为其他类。它为什么如此重要？开发人员可能想要管理负责实现特定类或接口的代码。与访问修饰符相比，密封类提供了一种更具声明性的方式来限制超类的使用。例如：
密封类的目的是让客户代码知道允许哪些子类。毕竟，在某些情况下，可能期望类（或接口）的原始定义是完全穷举的，并且开发人员不允许将其扩展到不受控制的范围，只有明确指定的类可以。
密封类有一些限制：
- 密封类及其允许的子类必须在同一模块中。如果在未命名的模块中声明它们，则必须将它们放在同一包中
- 每个允许的子类都必须直接扩展密封的类
- , , , — final, sealed nonsealed ( )
用于instanceof的模式匹配（JEP 375）。第二个预览是Project Amber的另一个开发。该功能的第一个初步版本是在Java 14中进行的，与之相比没有任何变化。
目标是通过对instanceof运算符进行模式匹配来改进Java。这使您可以更简洁，安全地表达程序中的常规逻辑，即从对象中有条件地提取组件。让我以Mal Gupta的出色文章“ Java 14中的instanceof模式匹配”为例。
参赛作品（JEP 384），第二稿。记录是充当不可变数据的透明载体的类。新的JEP包括基于社区反馈的说明，并支持几种新的其他形式的本地类和接口。条目也来自琥珀项目。
记录是一种面向对象的构造，表示简单的值聚合。因此，它们帮助程序员专注于对不可变数据进行建模，而不是对可扩展行为进行建模。记录自动实现数据驱动的方法，例如equals和accessors。这些条目还保留了长期的Java原则，例如标称类型和迁移兼容性。换句话说，它们使编写和读取包含不可变数据的类变得更加容易。
外部存储器访问（JEP 383）是API的第二个孵化器版本，它允许Java程序安全有效地访问Java堆外部的外部存储器。目标是开始替换java.nio.ByteBuffer和sun.misc.Unsafe。它是Panama项目的一部分，该项目改善了Java与其他API之间的通信。
JEP恰当地描述了这种创新的需求，如下所示：
在访问外部内存时，开发人员面临一个难题-他们是否应该选择安全但受限（且可能效率较低）的路径（例如ByteBuffer API），还是应该这样做？放弃安全保证并采用危险且不受支持的Unsafe API？
该JEP引入了用于访问外部存储器的安全，可维护和高效的API。通过为外部存储器访问问题提供有针对性的解决方案，开发人员将摆脱现有API的局限和危险。由于新API是从头开始设计的，并且考虑了JIT优化，因此它们还将获得更好的性能。
撤除和终止支持
这些决定都不应该引起争议。
删除Nashorn JavaScript引擎（JEP 372）。 Java 11中已弃用该引擎，其API和jjs工具。该说再见了。
禁用和消除保留锁定（JEP 374）消除了HotSpot JVM使用的旧优化技术，以减少与未检查锁定相关的开销。从历史上看，这种锁定已使性能大大超过了常规锁定方法，但过去所看到的性能提升如今已不那么明显了。在现代处理器上执行原子指令的成本已经下降。
冗余锁定导致大量复杂的代码，并且这种复杂性阻止Java开发团队对同步引擎进行重大更改。通过禁用该锁，并让程序员重新启用它，Java开发团队希望确定在将来的发行版中完全删除它是否明智。
删除Solaris和SPARC端口（JEP 381）。在这种情况下，将删除所有特定于Solaris操作系统和SPARC体系结构的源代码。没什么可说的了。
排除RMI激活以供以后卸载（JEP 385）。通过删除Java 8中可选的调用远程方法的过时部分来简化Java。减少了
RMI激活的使用。 Java团队看不到任何证据表明已使用它编写了任何新应用程序，并且有证据表明现有应用程序很少使用RMI激活。在搜索各种开源代码库时，几乎没有提及与其关联的任何API。几年来没有关于外部生成的RMI激活错误的报告。
作为Java平台的一部分支持RMI激活会产生持续的维护成本。这增加了RMI的复杂性。您可以删除RMI激活，而不会影响其余的RMI。删除它不会降低Java开发人员的价值，但确实会降低JDK的长期维护成本。
结论
Java 15延续了六个月的发布周期，是对大多数开发人员有用的中型版本。