JDK18功能先知
这个版本将是JavaSE平台版本18的参考实现，正如Java社区进程中JSR393所指定的那样。
状态
JDK18当前处于Rapdown one阶段。整个功能集已冻结。针对此版本将不再添加JEPs。
这个稳定版的jdk18是开源的，同样可以根据JDK发布流程（JEP 3）进行部分bug修复和后期增强。
新功能
-
JEP 400：UTF-8作为默认
概述
- 指定 UTF-8 作为标准 Java API 的默认字符集。通过此更改，依赖于默认字符集的 API 将在所有实现、操作系统、区域设置和配置中保持一致。
目标
-
当Java程序的代码依赖于默认字符集时，使其更可预测和可移植。
-
阐明标准JavaAPI在何处使用默认字符集。
-
通过标准Java API对UTF-8进行标准化，控制台I/O除外。
-
JEP 408：简单Web服务器
概述
- 引入一个简单的 Web 服务器。提供一个命令行工具，来启动一个只提供静态文件的最小网络服务器，它没有 CGI 或类似 servlet 的功能可用。该工具用于原型设计、临时编码和测试目的，尤其是在教学环境中。
目标
-
提供一个开箱即用的静态HTTP文件服务器，具有简单的设置和最少的功能。
-
降低开发人员的激活能，使JDK更容易接近。
-
通过命令行提供一个默认实现，以及一个用于编程创建和自定义的小API。
-
JEP 413 ：Java API文档中添加Snippet代码
概述
- 支持在 Java API 文档中加入代码片段。为 JavaDoc 的 Standard Doclet 引入一个 @snippet 标记，以简化 API 文档中嵌入示例源代码的难度。
目标
-
通过提供对源代码片段的API访问，促进源代码片段的验证。尽管正确性最终是作者的责任，但javadoc和相关工具中增强的支持可以使其更容易实现。
-
启用现代样式，例如语法高亮显示，以及名称与声明的自动链接。
-
为创建和编辑代码段提供更好的IDE支持。
-
JEP 416 ：用方法句柄重新实现核心反射
概述
- 用方法句柄重新实现核心反射。在 java.lang.invoke 的方法句柄之上，重构 java.lang.reflect 的方法、构造函数和字段，使用方法句柄处理反射的底层机制将减少 java.lang.reflect 和 java.lang.invoke 两者的 API 维护和开发成本。
-
JEP 417 ：Vector API（这里是矢量还是向量，不是很确定）
概述
- Vector API（第三孵化器）。引入一个 API 来表达向量计算，这些计算在运行时可以编译为支持的 CPU 架构上的最佳向量指令，从而实现优于等效标量计算的性能。
目标
-
清晰简洁的API - 该API应能够清晰简洁地表达广泛的向量计算，包括循环内的向量操作序列，可能还有控制流。应该可以表示关于向量大小或每个向量的车道数的通用计算，从而使此类计算能够跨支持不同向量大小的硬件进行移植。
-
平台无关 - API应该是CPU架构无关的，支持在支持向量指令的多个架构上实现。与Java API中的常见情况一样，平台优化和可移植性之间存在冲突，因此偏向于使API可移植，即使这会导致某些特定于平台的习惯用法无法在可移植代码中表达。
-
x64和AArch64体系结构上的可靠运行时编译和性能 - 在可运行Java的x64体系结构上时，特别是HotSpot C2编译器，应将向量操作编译为相应的高效和性能向量指令，例如，由数据流单指令多数据扩展指令集（SSE）和高级向量扩展指令集（AVX）支持的指令集。开发人员应该确信他们所表达的向量操作将可靠地映射到相关向量指令。同样，在功能强大的ARM AArch64体系结构上，C2将把向量操作编译为NEON和SVE支持的向量指令。
-
优雅降级 - 有时向量计算不能在运行时完全表示为向量指令序列，可能是因为体系结构不支持某些必需的指令。在这种情况下，向量API实现应该优雅地降级，并且仍能正常工作。如果向量计算无法有效编译为向量指令，则可能会发出警告。在没有向量的平台上，优雅的降级将产生与手动展开环路竞争的代码，其中展开因子是选定向量中的车道数。
-
JEP 418 ：互特网地址解析
概述
- 互联网地址解析 SPI。定义用于主机名和地址解析的服务提供者接口 (SPI)，以便java.net.InetAddress可以使用平台内置解析器以外的解析器。
-
JEP 419 ：外部函数和内存API
概述
- 外部函数和内存 API（第二孵化器）。引入了一个新 API, Java 程序可以通过它与 Java 运行时之外的代码和数据进行互操作。通过有效地调用外部函数(即 JVM 外的代码)，并安全地访问外部内存(即不由 JVM 管理的内存)，外部函数和内存 API 使 Java 程序能够调用本机库并处理本机数据，而不具有 JNI 的脆弱性和危险。
目标
-
易用性 - 用一个优秀的纯Java开发模型替换Java本机接口（JNI）。
-
性能 - 提供与现有API（如JNI和sun）相当（如果不是更好的话）的性能。非安全的。
-
通用性 - 提供操作不同类型的外部存储器（例如，本地内存、持久内存和托管堆内存）的方法，并且随着时间的推移，以适应其他平台（例如，32位x86）和用C以外的语言编写的外部函数（例如，C++、FORTRAN）。
-
安全 - 默认情况下禁用不安全操作，仅在应用程序开发人员或最终用户明确选择加入后才允许执行这些操作。
-
JEP 420 ： switch模式匹配
概述
- switch 模式匹配表达式。使用 switch 表达式和语句的模式匹配以及对模式语言的扩展来增强 Java 编程语言。将模式匹配扩展到 switch 允许针对多个模式测试表达式，每个模式都有特定的操作，可以简洁安全地表达复杂的面向数据的查询。
目标
-
通过允许模式出现在大小写标签中，扩展开关表达式和语句的表达能力和适用性。
-
允许在需要时放宽switch的历史空值。
-
引入两种新的模式：
- <font color=deeppink>保护模式</font> - 允许使用任意布尔表达式。细化模式匹配逻辑。
- <font color=deeppink>括号模式</font> - 解决一些解析歧义。
-
确保所有现有的switch表达式和语句继续编译而不做任何更改，并以相同的语义执行。
-
不要引入一个新的类似switch的表达式或语句，该表达式或语句具有与传统switch构造分离的模式匹配语义。
-
当大小写标签为模式时，不要使switch表达式或语句的行为与大小写标签为传统常量时的行为不同。
-
JEP 421 ：弃用 Finalization 功能
概述
- 弃用 Finalization 功能。Java 1.0 中引入的 Finalization 旨在帮助避免资源泄漏问题，然而这个功能存在延迟不可预测、行为不受约束，以及线程无法指定等缺陷，导致其安全性、性能、可靠性和可维护性方面都存在问题，因此将其弃用，用户可选择迁移到其他资源管理技术，例如try-with-resources 语句和清洁器。
目标
-
帮助开发人员了解最终确定的危险。
-
让开发人员做好准备，以便在将来的Java版本中删除。
-
提供简单的工具来帮助检测对定稿的依赖。
* 官方相关资料
网友评论