跳至主要內容

10. JDK17 新特性

PangHu大约 7 分钟

参考网站： openjdk.org/projects/jd…

306:
Restore Always-Strict Floating-Point Semantics恢复始终严格的浮点语义
356:
Enhanced Pseudo-Random Number Generators增强型伪随机数发生器
382:
New macOS Rendering Pipeline新的 macOS 渲染管道
391:
macOS/AArch64 PortMacOS/AArch64端口
398:
Deprecate the Applet API for Removal废弃 Applet API 以便删除
403:
Strongly Encapsulate JDK Internals强封装 JDK 内部结构
406:
Pattern Matching for switch (Preview)开关模式匹配(预览)
407:
Remove RMI Activation删除 RMI 激活
409:
Sealed Classes密封类
410:
Remove the Experimental AOT and JIT Compiler删除实验性 AOT 和 JIT 编译器
411:
Deprecate the Security Manager for Removal取消安全管理器以便删除
412:
Foreign Function & Memory API (Incubator)外部函数和内存 API (孵化器)
414:
Vector API (Second Incubator)矢量 API (第二个孵化器)
415:
Context-Specific Deserialization Filters特定于上下文的反序列化过滤器
JDK 17 will be a long-term support (LTS) release from most vendors. For a complete list of the JEPs integrated since the previous LTS release, JDK 11, please see here.
JDK 17将是来自大多数供应商的长期支持(LTS)版本。有关自上一个 LTS 版本 JDK 11以来集成的 JEP 的完整列表，请参阅这里。

10.1 Context-Specific Deserialization Filters（上下文特定的反序列化过滤器）

Context-Specific Deserialization Filters（上下文特定的反序列化过滤器）是 JDK 17 中引入的一个特性，用于增强 Java 应用程序对反序列化过程的控制和安全性。 在 Java 中，反序列化是将对象从字节序列还原为内存中的对象的过程。然而，反序列化操作可能存在安全风险，因为恶意序列化数据可以触发未经授权的代码执行或对象创建。 Context-Specific Deserialization Filters 允许开发人员定义特定于上下文的反序列化过滤器，以限制哪些类可以被反序列化。开发人员可以在特定的上下文中设置反序列化过滤器，例如在应用程序的安全管理器中、在 RMI 远程调用中、在对象输入流的特定实例上等。 通过定义上下文特定的反序列化过滤器，开发人员可以实现以下目标：

  1. 类过滤：可以定义白名单或黑名单，只允许或禁止特定的类进行反序列化。这有助于限制潜在的安全风险和不受信任的类的反序列化。
  2. 内容检查：可以对反序列化的对象进行更严格的验证和检查，以确保数据的完整性和合法性。
  3. 安全策略实施：可以通过上下文特定的反序列化过滤器实施特定的安全策略，以满足应用程序的需求和要求。

通过使用 Context-Specific Deserialization Filters，开发人员可以在反序列化过程中更细粒度地控制和验证对象的创建和内容。这有助于提高应用程序的安全性，减少潜在的安全漏洞和攻击面。

10.2 Strong encapsulation of JDK internals（JDK 内部模块的强封装）

Strong encapsulation of JDK internals（JDK 内部模块的强封装）是 JDK 17 中引入的一个特性，旨在进一步限制和封装 JDK 内部模块的访问。 在 Java 9 中，引入了模块系统（Module System），通过将 JDK 分为一组模块来提供更严格的访问控制和模块化。然而，在较早版本的 JDK 中，某些 JDK 内部模块的访问级别仍然比较宽松，可能会导致潜在的不安全和不稳定的代码依赖关系。 JDK 17 引入了 Strong encapsulation 特性，通过进一步限制和封装 JDK 内部模块的访问，以提高系统的安全性和稳定性。具体来说，它包括以下方面：

  1. JDK 内部 API 的强封装：许多 JDK 内部 API 在 JDK 17 中被标记为强封装，不再公开为公共 API。这些 API 的访问级别被限制在 JDK 内部，开发人员不应直接访问或依赖这些 API。
  2. 模块的强封装：JDK 17 强化了一些 JDK 内部模块的封装，以防止外部模块直接访问这些内部模块。这增加了对 JDK 内部实现细节的保护，降低了对内部模块的直接依赖。

通过强封装 JDK 内部模块，可以减少对不稳定的和非正式的 API 的依赖，并提高应用程序的可靠性和可移植性。这也促使开发人员使用公共和稳定的 API，以确保应用程序在不同版本的 JDK 上的兼容性。 需要注意的是，在使用 JDK 17 时，如果应用程序依赖于 JDK 内部的 API 或模块，可能会受到这种强封装的影响。

10.3 Sealed JNI（密封 JNI）

Sealed JNI（密封 JNI）是 JDK 17 中引入的一个特性，旨在限制本机接口（JNI）的实现，以提高本机代码的安全性。 JNI 是 Java Native Interface 的缩写，它允许 Java 程序与本机代码进行交互。通过 JNI，Java 程序可以调用本机库中的函数，也可以从本机代码中调用 Java 方法。然而，JNI 也带来了一些安全风险，因为不受信任的本机代码可能会访问和修改 Java 程序的内部状态。 Sealed JNI 引入了密封 JNI 的概念，通过限制本机接口的实现来提高本机代码的安全性。具体来说，Sealed JNI 可以通过以下方式实现：

  1. 密封本机接口库：开发人员可以将本机接口库标记为密封（sealed），以限制它的实现。密封本机接口库只能在特定的上下文中使用，例如指定的模块、类加载器或其他条件。
  2. 安全策略的强制执行：通过密封 JNI，可以强制执行安全策略，只允许受信任的本机接口库进行调用。这可以减少潜在的恶意或不安全的本机代码对 Java 程序的影响。

Sealed JNI 的目标是提高本机代码的安全性，并减少与不受信任的本机代码相关的潜在风险。开发人员可以使用密封 JNI 来限制本机接口库的使用范围，并确保只有受信任的代码可以调用本机方法。

10.4 改进的垃圾收集器

在 JDK 17 中，进行了一些改进和优化，以提供更好的垃圾收集器性能和稳定性。以下是一些与垃圾收集器相关的改进：

  1. ZGC：ZGC 是一种低延迟的垃圾收集器，旨在减少应用程序的停顿时间。在 JDK 17 中，ZGC 进行了一些改进，包括改进的内存分配、增强的并发处理和更好的性能。
  2. Shenandoah GC：Shenandoah GC 是另一种低延迟的垃圾收集器，适用于大内存堆的应用程序。在 JDK 17 中，Shenandoah GC 进行了一些改进，包括更好的垃圾收集算法、并发处理和性能优化。
  3. G1 GC 改进：G1（Garbage-First）是一种面向大堆和低停顿的垃圾收集器。在 JDK 17 中，对 G1 GC 进行了一些改进，包括性能优化、内存分配改进和更好的并发处理。
  4. 垃圾收集器接口：JDK 17 引入了一组新的垃圾收集器接口，允许开发人员实现自定义的垃圾收集器。这样，开发人员可以根据自己的需求和场景开发定制的垃圾收集器。

这些改进和优化旨在提供更好的垃圾收集器性能、降低停顿时间，并提高大堆和低延迟应用程序的吞吐量。具体的改进和优化细节可以在 JDK 17 的发行说明和相关文档中找到。