JDK 17 新特性概览
JEP 306: Restore Always-Strict Floating-Point Semantics
Make floating-point operations consistently strict, rather than have both strict floating-point semantics (strictfp) and subtly different default floating-point semantics. This will restore the original floating-point semantics to the language and VM, matching the semantics before the introduction of strict and default floating-point modes in Java SE 1.2.
JEP 306: 恢复始终严格的浮点语义
使浮点操作始终保持严格，而不是同时具有严格浮点语义（strictfp）和略有不同的默认浮点语义。这将恢复语言和虚拟机的原始浮点语义，与Java SE 1.2引入严格和默认浮点模式之前的语义相匹配。
JEP 356: Enhanced Pseudo-Random Number Generators
Provide new interface types and implementations for pseudorandom number generators (PRNGs), including jumpable PRNGs and an additional class of splittable PRNG algorithms (LXM).
JEP 356: 增强的伪随机数生成器
提供新的接口类型和伪随机数生成器（PRNG）的实现，包括可跳跃的PRNG和一种额外的可分割PRNG算法类（LXM）。
JEP 382: New macOS Rendering Pipeline
Implement a Java 2D internal rendering pipeline for macOS using the Apple Metal API as alternative to the existing pipeline, which uses the deprecated Apple OpenGL API.
JEP 382: 新的macOS渲染管道
为macOS实现一个Java 2D内部渲染管道，使用Apple Metal API作为现有管道的替代，后者使用已弃用的Apple OpenGL API。
JEP 391: macOS/AArch64 Port
Port the JDK to macOS/AArch64.
JEP 391: macOS/AArch64 移植
将 JDK 移植到 macOS/AArch64。
JEP 398: Deprecate the Applet API for Removal
Deprecate the Applet API for removal. It is essentially irrelevant since all web-browser vendors have either removed support for Java browser plug-ins or announced plans to do so.
JEP 398: 废弃Applet API以便移除
废弃Applet API以便移除。由于所有网页浏览器供应商已删除对Java浏览器插件的支持或宣布计划这样做，因此该API基本上已无关紧要。
JEP 403: Strongly Encapsulate JDK Internals
Strongly encapsulate all internal elements of the JDK, except for critical internal APIs such as sun.misc.Unsafe. It will no longer be possible to relax the strong encapsulation of internal elements via a single command-line option, as was possible in JDK 9 through JDK 16.
JEP 403: 强封装JDK内部
强封装JDK的所有内部元素，除了关键内部API如sun.misc.Unsafe。将不再可能通过单个命令行选项放宽内部元素的强封装，这在JDK 9到JDK 16之间是可以实现的。
JEP 406: Pattern Matching for switch (Preview)
Enhance the Java programming language with pattern matching for switch expressions and statements, along with extensions to the language of patterns. Extending pattern matching to switch allows an expression to be tested against a number of patterns, each with a specific action, so that complex data-oriented queries can be expressed concisely and safely. This is a preview language feature in JDK 17.
JEP 406: switch 的模式匹配（预览）
通过为 switch 表达式和语句增强模式匹配以及对模式语言的扩展，来增强 Java 编程语言。将模式匹配扩展到 switch 允许对多个模式进行测试，每个模式都有特定的操作，从而可以简洁而安全地表达复杂的数据导向查询。这是 JDK 17 中的 预览语言特性。
JEP 407: Remove RMI Activation
Remove the Remote Method Invocation (RMI) Activation mechanism, while preserving the rest of RMI.
JEP 407: 移除RMI激活
移除远程方法调用（RMI）激活机制，同时保留RMI的其余部分。
JEP 409: Sealed Classes
Enhance the Java programming language with sealed classes and interfaces. Sealed classes and interfaces restrict which other classes or interfaces may extend or implement them.
JEP 409: 密封类
通过引入密封类和接口增强Java编程语言。密封类和接口限制了哪些其他类或接口可以扩展或实现它们。
JEP 410: Remove the Experimental AOT and JIT Compiler
Remove the experimental Java-based ahead-of-time (AOT) and just-in-time (JIT) compiler. This compiler has seen little use since its introduction and the effort required to maintain it is significant. Retain the experimental Java-level JVM compiler interface (JVMCI) so that developers can continue to use externally-built versions of the compiler for JIT compilation.
JEP 410: 移除实验性的AOT和JIT编译器
移除实验性的基于Java的提前编译（AOT）和即时编译（JIT）编译器。自引入以来，该编译器的使用很少，维护所需的工作量很大。保留实验性的Java级JVM编译器接口（JVMCI），以便开发人员可以继续使用外部构建的编译器版本进行JIT编译。
JEP 411: Deprecate the Security Manager for Removal
Deprecate the Security Manager for removal in a future release. The Security Manager dates from Java 1.0. It has not been the primary means of securing client-side Java code for many years, and it has rarely been used to secure server-side code. To move Java forward, we intend to deprecate the Security Manager for removal in concert with the legacy Applet API (JEP 398).
JEP 411: 弃用安全管理器以便移除
在未来的版本中弃用安全管理器以便移除。安全管理器自Java 1.0以来就存在。多年来，它一直不是保护客户端Java代码的主要手段，并且很少用于保护服务器端代码。为了推动Java的发展，我们打算与遗留的Applet API（JEP 398）一起弃用安全管理器以便移除。
JEP 412: Foreign Function & Memory API (Incubator)
Introduce an API by which Java programs can interoperate with code and data outside of the Java runtime. By efficiently invoking foreign functions (i.e., code outside the JVM), and by safely accessing foreign memory (i.e., memory not managed by the JVM), the API enables Java programs to call native libraries and process native data without the brittleness and danger of JNI.
JEP 412: 外部函数与内存 API (孵化器)
引入一个 API，使 Java 程序能够与 Java 运行时之外的代码和数据进行交互。通过高效地调用外部函数（即 JVM 之外的代码）和安全地访问外部内存（即不由 JVM 管理的内存），该 API 使 Java 程序能够调用本地库并处理本地数据，而无需 JNI 的脆弱性和危险性。
JEP 414: Vector API (Second Incubator)
Introduce an API to express vector computations that reliably compile at runtime to optimal vector instructions on supported CPU architectures, thus achieving performance superior to equivalent scalar computations.
JEP 414: 向量API（第二次孵化）
引入一个API，用于表达向量计算，该API能够在运行时可靠地编译为支持的CPU架构上的最佳向量指令，从而实现优于等效标量计算的性能。
JEP 415: Context-Specific Deserialization Filters
Allow applications to configure context-specific and dynamically-selected deserialization filters via a JVM-wide filter factory that is invoked to select a filter for each individual deserialization operation.
JEP 415: 上下文特定的反序列化过滤器
允许应用程序通过一个JVM范围内的过滤器工厂配置上下文特定和动态选择的反序列化过滤器，该工厂在每个单独的反序列化操作中被调用以选择过滤器。