Java 17 新特性—概述

最新推荐文章于 2024-09-25 17:43:01 发布

smart哥

最新推荐文章于 2024-09-25 17:43:01 发布

阅读量935

点赞数 19

分类专栏： java新特性文章标签： java17新特性

本文链接：https://blog.csdn.net/smart_an/article/details/141657180

版权

java新特性专栏收录该内容

65 篇文章 3 订阅

订阅专栏

作者简介：大家好，我是smart哥，前中兴通讯、美团架构师，现某互联网公司CTO

联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬

学习必须往深处挖，挖的越深，基础越扎实！

阶段1、深入多线程

 阶段2、深入多线程设计模式

 阶段3、深入juc源码解析

阶段4、深入jdk其余源码解析

阶段5、深入jvm源码解析

码哥源码部分

码哥讲源码-原理源码篇【2024年最新大厂关于线程池使用的场景题】

码哥讲源码【炸雷啦！炸雷啦！黄光头他终于跑路啦！】

码哥讲源码-【jvm课程前置知识及c/c++调试环境搭建】

码哥讲源码-原理源码篇【揭秘join方法的唤醒本质上决定于jvm的底层析构函数】

码哥源码-原理源码篇【Doug Lea为什么要将成员变量赋值给局部变量后再操作？】

码哥讲源码【你水不是你的错,但是你胡说八道就是你不对了！】

码哥讲源码【谁再说Spring不支持多线程事务，你给我抽他！】

终结B站没人能讲清楚红黑树的历史，不服等你来踢馆！

打脸系列【020-3小时讲解MESI协议和volatile之间的关系，那些将x86下的验证结果当作最终结果的水货们请闭嘴】

Java 17，发布于 2021 年 9 月，是一个长期支持（LTS）版本。

JEP 356：增强型伪随机数生成器

在 Java 17 之前，Java 的伪随机数生成主要依赖于 java.util.Random 类及其子类，如 ThreadLocalRandom 和 SecureRandom。这些类虽然功能强大，但在某些特定应用场景中存在局限性，如需要特定类型的随机数生成器（例如具有更长周期的生成器），或需要更细粒度的控制和更广泛的算法选择。

Java 17 引入增强的伪随机数生成器其目的是在 Java 标准库中引入更多种类的随机数生成器，并提供一种更为统一且易于使用的方式来访问和使用这些生成器。它的主要内容包括：

新的接口和实现：引入新的接口 RandomGenerator，以及多个实现此接口的类，每个类代表一种不同类型的随机数生成器。
更广泛的算法选择：提供了多种基于不同算法的随机数生成器，比如 LCG（线性同余生成器）、Xoroshiro、Xoshiro 等，每种算法都有其特点和适用场景。
更好的性能和质量：新的生成器在性能和生成数质量方面进行了优化，以满足更加复杂和高效的应用需求。

JEP 382：新的 macOS 渲染管线

在 Java 17 之前，Java 在 macOS 平台上的图形渲染主要依赖于 OpenGL。随着 Apple 宣布逐步废弃 OpenGL 支持，并推荐使用更现代的 Metal API，Java 需要适应这一变化，以确保其在 macOS 平台上的图形性能和兼容性。

该特性是引入一个新的渲染管道，使用 Apple 的 Metal API 替代 OpenGL。目前默认情况下，这是禁用的，因此渲染仍然使用OpenGL API；要启用metal，应用程序应通过设置系统属性指定其使用：

-Dsun.java2d.metal=true

JEP 391：macOS/AArch64 端口

由于早期的 Java 版本并不支持在 ARM 架构的 M1 上运行，这就需要 Java 在 macOS 上支持 ARM64 架构（即 AArch64），从而确保 Java 应用程序和开发者能够在这个新平台上继续运行和开发。

Java 17 引入该特性，去主要目标是在 macOS 上为 ARM64 架构（AArch64）提供官方支持，解决以下问题：

兼容性：确保 Java 可以在 Apple 的 M1 芯片上顺利运行。
性能：优化 Java 在 ARM64 架构上的性能，使其充分利用 M1 芯片的高效能。

JEP 398：移除 Applet API

Applet API 是 Java 最早期的组成部分之一，它允许在浏览器中运行 Java 程序。随着时间的推移，网络技术发展，特别是 HTML5 和 JavaScript 的崛起，使得 Applet 的重要性大大降低。同时，Applets 通常需要浏览器插件来运行，这导致了安全性问题和兼容性问题。且随着主流浏览器逐渐放弃对 Java 插件的支持，Applet 的实用性进一步下降。

Java 17 将Applet API 标记为弃用，并在未来的 Java 版本中移除它。

JEP 406：模式匹配的 Swith 表达式（预览）

在 Java 16 中， JEP 394 扩展了 instanceof 运算符，可以采用类型模式并执行模式匹配。虽然可以不需要强制转换了，但是仍然需要大量的 if...else。而 Switch 表达式虽然简化了 if...else ，但是它无法像 instanceof 一样不需要强制转换。为了解决这个痛点，Java 17 引入模式匹配的 Switch 表达式特性，目前该特性为预览特性。

该特性扩展了 switch 表达式和语句，允许它们使用模式匹配，这就意味着我们可以在 switch 的 case 标签中使用模式，如类型模式，使得代码更加灵活和表达性更强。而且也无需进行显式的类型转换了。例如，可以使用 case Integer i 这样的语法来匹配并自动转换类型。

JEP 407：删除 RMI 激活

RMI (远程方法调用) 激活系统是 Java RMI 框架的一部分，它允许远程激活对象。它在 Java 15 中被标记为弃用，Java 17 删除 RMI 激活。

JEP 409：密封类（正式特性）

为了限制 Java 的继承，Java 15 引入密封类作为预览特性。密封类允许类设计者明确控制哪些其他类或接口可以实现或扩展它们，从而提供更精确的多态性控制。同时，Java 16 第二次作为预览特性，最终在 Java 17 中成为正式特性。

Java 版本	更新类型	JEP	更新内容
Java 15	预览特性	JEP 360	引入了密封类作为预览特性。
Java 16	第二次预览	JEP 397
Java 17	正式特性	JEP 409	成为正式特性。

JEP 410：移除实验性的 AOT 和 JIT 编译

Java 9 引入了实验性的 Ahead-of-Time (AOT) 编译器和一个实验性的 Just-In-Time (JIT) 编译器，即 Graal 编译器。这些特性最初被引入是为了探索和评估在 Java 虚拟机中提供不同类型编译器的可能性。经过一段时间的实验和社区反馈，发现这些实验性编译器的维护成本较高，而且在实际应用中的使用率并不高。

故而，Java 17 将 Jaotc AOT 编译器和基于 Graal 编译器的实验性 JIT 编译器移除。这样可以简化 JDK 的代码库，降低维护成本。

JEP 411：废弃安全管理器

安全管理器是 Java 平台的一部分，用于提供对 Java 应用的安全限制。它在早期 Java 版本中是重要的安全特性，用于控制 Applets 和其他类型的应用的权限。但是，随着 Java 平台的发展和安全模型的演进，安全管理器的重要性逐渐降低，现代应用通常通过操作系统级别的安全措施和应用架构设计来实现安全。

Java 17 将安全管理器标记为弃用，并在将来的版本中移除。

JEP 412：外部函数与内存 API（第二次孵化）

传统上，Java 使用 Java Native Interface (JNI) 来与本地代码互操作。虽然功能强大，但 JNI 使用复杂且易出错，且性能开销较大。

Java 17 引入一套新的 API，使得 Java 程序能够安全、高效地调用外部函数（如 C 语言函数）和操作外部内存。API 包括：

引入了外部函数接口，允许 Java 程序调用 C 语言等外部语言编写的函数。
引入了外部内存接口，允许 Java 程序安全地访问和操作本地内存。

Java 版本	更新类型	JEP	更新内容
Java 14	孵化器	JEP 370	引入了外部内存访问 API
Java 15	第二孵化器	JEP 383	优化外部内存访问 API
Java 16	孵化器	JEP 389	引入了外部链接器 API
Java 16	第三孵化器	JEP 393	继续优化
Java 17	孵化器	JEP 412	引入了外部函数和内存 API

JEP 414：向量 API（第二次孵化）

向量 API 是在 Java 16 中作为孵化器引入的，主要是解决 Java 在进行高性能数值计算时的性能限制。Vector API 通过提供一套标准的 API，使得 Java 程序能够以一种高效、简洁且跨平台一致的方式进行向量计算。

Java 17 基于此前版本的反馈和经验进行了改进，第二次孵化。

Java 版本	更新类型	JEP	更新内容
Java 16	第一次孵化	JEP 338	提供一个平台无关的方式来表达向量计算，能够充分利用现代处理器上的向量硬件指令。
Java 17	第二次孵化	JEP 414	对 API 进行了改进，增加了性能优化和新的功能。