java17新特性汇总(Java15即将到来)
java17新特性汇总(Java15即将到来)记录是充当不可变数据的透明载体的类,在 JDK 14 中作为早期预览版首次亮相后,将包含在 JDK 15 中的第二个预览版本中。该计划的目标包括设计一个面向对象的构造,该构造表示值的简单聚合,帮助程序员专注于对不可变数据建模,而不是可扩展行为,自动实现数据驱动方法(如等值器和评估器),以及保留长期存在的 Java 原则(如名义类型和迁移兼容性)。记录可视为名义元组。删除源代码并构建对 Solaris/SPARC、Solaris/x64 和 Linux/SPARC 端口的支持,这些端口在 JDK 14 中已弃用,目的是在将来的版本中删除它们。许多项目和功能在开发中,如 Valhalla、Loom 和 Panama 都需要对 CPU 架构和操作系统特定的代码进行重大更改。放弃对 Solaris 和 SPARC 端口的支持将使 OpenJDK 社区的贡献者能够加速开发新功能,从而推动平台向前发展
编译 | 苏宓
头图 | CSDN 下载自视觉中国
出品 | CSDN(ID:CSDNnews)
按照 Oracle 六个月一更新的周期来看,JDK 15 即将于今年 9 月 15 日发布。据了解,目前新版的 java 处于发布候选阶段,包含文本块、垃圾收集器、隐藏类以及模式匹配和记录的功能预览版。
在发布前夕,我们不妨先一窥新版 JDK 的新特性:
-
第二个外部内存访问 API(孵化阶段),它将使 Java 程序安全高效地访问 Java 堆以外的外部存储器。该 API 应该能够在各种外部内存(如本机、持久和托管堆)上进行操作。许多 Java 程序访问外部存储器,如 lgnite 和 MapDB。API 有助于避免与垃圾回收相关的成本和不可预测性,跨进程共享内存以及通过将文件映射到内存,来序列化和取消序列化内存内容。Java API 目前无法提供令人满意的访问外部内存的解决方案。但是,随着新提案的提出,API 不应损害 JVM 的安全性。此功能正在 JDK 14 中进入较早的孵化器阶段,JDK 15 中提供了改进。
-
密封类的预览版。密封类与接口一起限制其他类或接口可以扩展或实现它们。此功能的目标包括允许类或接口的开发者控制负责实现该代码,提供比访问修饰符更具声明性的方式来限制超类的使用,以及通过支持详尽的内容来支持模式匹配的未来方向。
-
删除源代码并构建对 Solaris/SPARC、Solaris/x64 和 Linux/SPARC 端口的支持,这些端口在 JDK 14 中已弃用,目的是在将来的版本中删除它们。许多项目和功能在开发中,如 Valhalla、Loom 和 Panama 都需要对 CPU 架构和操作系统特定的代码进行重大更改。放弃对 Solaris 和 SPARC 端口的支持将使 OpenJDK 社区的贡献者能够加速开发新功能,从而推动平台向前发展。近年来,Solaris 和 SPARC 都已被 Linux 操作系统和英特尔处理器取代。
-
记录是充当不可变数据的透明载体的类,在 JDK 14 中作为早期预览版首次亮相后,将包含在 JDK 15 中的第二个预览版本中。该计划的目标包括设计一个面向对象的构造,该构造表示值的简单聚合,帮助程序员专注于对不可变数据建模,而不是可扩展行为,自动实现数据驱动方法(如等值器和评估器),以及保留长期存在的 Java 原则(如名义类型和迁移兼容性)。记录可视为名义元组。
-
基于爱德华兹曲线数字签名算法(EdDSA) 的加密签名。EdDSA 是一种现代椭圆曲线方案,与 JDK 中现有的签名方案相比具有优势。EdDSA 将仅在 SunEC 提供程序中实现。与其他签名方案相比,EdDSA 的安全性和性能有所提高,因此对其需求更为强烈,目前,它已在 OpenSSL 和 BoringSSL 等加密库中得到支持。
-
通过替换 java.net.datagram 的基础实现,重新实现旧版 DatagramSocket API。Socket 和 java.net.MulticastSocket API 具有更简单、更现代的实现方式,即:1. 易于调试和维护;2. 与 Project Loom 中正在探索的虚拟线程一起使用。新计划是 JDK 增强建议 353 的后续行动,该提案重新实现旧版 Socket API。java.net.datagram.Socket 和 java.net.MulticastSocket 的当前实现可追溯到 JDK 1.0,而 IPv6 仍在开发中。因此,MulticastSocket 的当前实现尝试以难以维护的方式协调 IPv4 和 IPv6。
-
默认情况下,禁用偏向锁定,并弃用所有相关的命令行选项。该目的是确定是否需要继续支持昂贵、具有维护成本的偏向锁定的传统同步优化,该优化用于 HotSpot 虚拟机,以减少无可调整锁定的开销。尽管某些 Java 应用程序可能会看到禁用偏锁定时性能下降,但偏置锁定的性能提升通常不如以前明显。
-
继 JDK 14 中的前一个预览之后,第二个模式匹配预览。模式匹配允许程序中的通用逻辑(主要是从对象中的条件提取组件)可以更简洁地表达。Haskell 和 C# 等语言已采用模式匹配来实现简洁和安全性。
-
隐藏类。即不能由其他类的字节码直接使用的类,供在运行时生成类并通过反射间接使用它们的框架使用。隐藏类可以定义为访问控制嵌套的成员,并且可以独立于其他类进行卸载。该提案通过启用标准 API 来定义无法发现且具有有限生命周期的隐藏类,从而提高 JVM 上所有语言的效率。JDK 内外的框架将能够动态生成类,而这些类可以定义隐藏类。基于 JVM 的许多语言都依赖于动态类生成,以实现灵活性和效率。该提案的目标包括:允许框架将类定义为框架的不可发现的实现细节,以便其他类不能将其链接,也不能通过反射发现;支持使用不可发现类扩展访问控制嵌套;并支持主动卸载不可发现类,因此框架可以灵活地定义尽可能多的类。另一个目标是弃用非标准 API misc.Unsafe::defineAnonymousClass,目的是在将来的版本中弃用。此外,Java 语言不会因此建议而更改。
-
根据提案,Z 垃圾收集器 (ZGC)将从实验版本过渡到产品中。ZGC 最初集成在 2018 年 9 月的 JDK 11 中,是一个可扩展的低延迟垃圾回收器。ZGC 是作为实验功能引入的,因为 Java 开发人员认为,这种规模和复杂性的功能应该谨慎且逐步地引入。自 2018 年以来,ZGC 已增加了许多改进,从并发类卸载、取消使用未使用的内存、对类数据共享的支持到改进的 NUMA 感知。此外,最大堆大小从 4 TB 增加到 16 TB。支持的平台包括 Linux、Windows 和 MacOS。
-
文本块。这一功能在 JDK 14 和 JDK 13 中都已实现预览版。它跨越多行源代码,同时避免在常见情况下的转义序列,从而简化编写 Java 程序的任务。文本块是一个字符串文字,它避免了大多数转义序列,以可预测的方式自动格式化字符串,并根据需要为开发人员提供了对该格式的控制权。文本块建议的目标是提高 Java 程序中的字符串的可读性,这些字符串表示以非 Java 语言编写的代码。另一个目标是支持从字符串文本迁移,规定任何新构造都可以表达与字符串文本相同的字符串集,解释相同的转义序列,并且以与字符串文本相同的方式进行操作。OpenJDK 开发人员希望添加转义序列来管理显式空白和换行控件。
-
低暂停时间的垃圾收集器 Shenandoah 将从实践阶段推向生产。一年前,该功能特性被加入了 JDK 12 中。
-
删除 Nashorn。该功能是 2014 年 3 月发布的 JDK 8 的新特性,但此后没多久就被诸如 GraalVM 等技术淘汰。根据提案,OpenJDK 15 建议要求删除 Nashorn API 和用于调用 Nashorn 的 jjs 命令行工具。
-
弃用 RMI 激活机制,这也是为了将来为这一功能移除做准备。事实上,自 Java 8 以来,RMI 激活机制一直作为是可选项而非必选项,这也被视为是 RMI 中过时的部分。当下,RMI 的激活机制如果不弃用会造成维护负担。同时据了解,RMI 的其他部分暂时不会被弃用。
目前,JDK 15 的早期访问版本可以尝鲜:http://jdk.java.net/15/。继长期版本 JDK 11 之后,JDK 12/13/14以及即将发布的 JDK 15 都将是一个短期版本。而下一个长期支持 (LTS) 版本将是 JDK 17,该版本预计于 2021 年 9 月发布。
那么对于即将发布的 JDK 15,你会更新吗?