首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

JDK 19最新动态和JDK 20 新特性预测

甲骨文 Java 平台组首席架构师 Mark Reinhold 宣布 JDK 19(JDK 17 之后的第二个非 LTS 版本)已经进入初始发布候选阶段。主线源代码库(2022 年 6 月初分叉到 JDK 稳定代码库)定义了 JDK 19 的特性集。关键的 Bug(如回归或严重的功能问题)得到了解决,但必须通过 Fix-Request 流程批准。根据发布计划,JDK 19 将在 2022 年 9 月 20 日正式发布。

最后一组(7 个)新特性(以 JEP 的形式)可以分为三类——核心 Java 库、Java 规范和 Hotspot 编译器。

被归类为核心 Java 库的 4 个新特性是:

被归类为 Java 规范的 2 个新特性是:

最后,被归类到 Hotspot 编译器的一个新特性是:

我们将介绍这些新特性,以及涵盖了这些新特性的四个主要 Java 项目——AmberLoomPanamaValhalla。这些项目旨在孵化出一系列组件,并最终经过合并包含在 JDK 中。

Amber

JEP 405,即记录模式(预览),提议用记录模式来解构记录值。记录模式可以与类型模式一起使用,“支持强大的、声明式的和可组合的数据浏览和处理形式”。类型模式最近已通过 JEP 406(即 switch 的模式匹配(预览),在 JDK 17 中交付)和 JEP 420(即 switch 的模式匹配(第二次预览),在 JDK 18 中交付)被用在 switch 的 case 子句中。更多关于 JEP 405 的细节可以在 InfoQ 的报道中看到。

JEP 427,即 switch 的模式匹配(第三次预览),针对前两轮预览反馈进行了增强——JEP 406(即 switch 的模式匹配(预览),在 JDK 17 中交付)和 JEP 420(即 switch 的模式匹配(第二次预览),在 JDK 18 中交付)。JEP 420 以来的变更包括——保护模式被替换为 switch 块中的 when 子句;当选择器表达式的值为空时,模式 switch 的运行时语义与遗留 switch 的语义更为接近。

Loom

JEP 425,即虚拟线程(预览),向 Java 平台引入了虚拟线程。这是一种轻量级线程,极大地减少了编写、维护和观察高吞吐量并发应用程序的工作量。更多关于 JEP 425 的细节可以在 InfoQ 的报道和甲骨文 Java 平台组开发者布道师 José Paumard 的 JEP Café屏播中找到。

JEP 428,即结构化并发(孵化器),提议通过引入一个新的库来简化多线程编程,这个库将运行在不同线程中的多个任务视为单个工作单元。这可以简化错误处理和取消操作,提高可靠性,并增强可观察性。更多关于 JEP 428 的细节可以在 InfoQ 的报道中看到。

Panama

JEP 424,即外部函数和内存 API(预览),为 Java 应用程序引入一个 API,通过高效调用外部函数和安全访问不受 JVM 管理的外部内存来实现与 Java 运行时之外的代码和数据的互操作。这个 JEP 演化自 JEP 419(即外部函数和内存 API(第二轮孵化器),在 JDK 18 中交付)和 JEP 412(即外部函数和内存 API(孵化器),在 JDK 17 中交付),并针对 Java 社区的反馈进行了增强。

JEP 426,即 Vector API(第四轮孵化器),根据前三轮孵化的反馈进行了改进——JEP 417(即 Vector API(第三轮孵化器),在 JDK 18 中交付)、JEP 414(即 Vector API(第二轮孵化器),在 JDK 17 中交付),以及 JEP 338(即 Vector API(孵化器),在 JDK 16 中作为孵化器模块交付)。JEP 426 提议对 Vector API 进行增强,从 MemorySegment(JEP 424,即外部函数和内存 API(预览))加载或存储 Vector。

Hotspot 编译器

JEP 422,即 Linux/RISC-V 移植,提议将 JDK 移植到 Linux/RISC-V(一种免费、开源的 RISC 指令集架构)上。移植版本将支持模板解释器、C1 和 C2 JIT 编译器以及所有当前的主要垃圾回收器,包括 ZGC 和 Shenandoah。这个 JEP 的主要重点是将移植的内容集成到 JDK 主线代码库中。

JDK 20

JDK 20 预计于 2023 年 3 月发布 GA 版本,目前还没有相关的 JEP。但是,根据最近提交的 JEP 草案和后续 JEP,我们可以推测哪些 JEP 有可能被包含在 JDK 20 中。

JEP 429,即扩展本地变量(孵化器),提议在线程内部和线程之间共享不可变数据。这要优于线程局部变量,特别是在使用大量虚拟线程时。更多关于 JEP 429 的细节可以在 InfoQ 的报道中看到。

JEP 草案 8277163,即值对象(预览),提议创建值对象——指定实例行为的无标识值类。这个草案与 JEP 401(原语类(预览),仍处于候选状态)相关。

JEP 401,即原语类(预览),引入了由开发者声明的原语类——在前面提到的值对象(预览)JEP 草案中定义的特殊类型的值类——定义了新的原语类型。

JEP 草案 8273943,即字符串模板(预览),提议使用字符串模板来增强 Java 语言。字符串模板类似于字符串字面量,但包含了嵌入表达式,在运行时将合并到字符串模板中。

JEP 草案 8280836,即有序集合,提议引入“一组新的接口来表示集合概念,这些集合中的元素按照定义良好的顺序进行排列,作为集合的结构属性。”这是由于 Java 的 Collections Framework 缺乏定义良好的顺序和统一操作。

JEP 草案 8284289,即改进的异步获取调用跟踪的方法,提议定义一个有效的 API,用于从信号处理器中获取用于分析的异步调用跟踪信息。

JEP 草案 8283227,即JDK源结构,用于描述 JDK 源代码和 JDK 代码库中相关文件的总体布局和结构。这个 JEP 建议帮助开发者适应 JEP 201(在 JDK 9 中交付的模块化源代码)所描述的源代码结构。

JEP 草案 8280389,即ClassFile API,提议提供一个用于解析、生成和转换 Java 类文件的 API。这个 JEP 在一开始将作为 JDK 内部的 ASM(Java 字节码操作和分析框架)替代品,并计划将其作为公共 API 开放出来。甲骨文 Java 语言架构师 Brian Goetz 将 ASM 描述为“一个带有大量遗留包袱的旧代码库”,并讲解了这个草案将如何演变并最终取代 ASM。

JEP 草案 8278252,即JDK打包和安装指南,提议为 macOS、Linux 和 Windows 平台提供创建 JDK 安装程序的指南,以降低不同 JDK 提供程序安装 JDK 时发生冲突的风险。其目的是通过规范化安装目录名称、包名和其他可能导致冲突的安装程序元素,在安装 JDK 更新版本时提供更好的用户体验。

我们预计甲骨文将很快开始将这些 JEP 中的一些或其他 JEP 包含在 JDK 20 中。

原文链接

JDK 19 and JDK 20: What We Know So Far

  • 发表于:
  • 本文为 InfoQ 中文站特供稿件
  • 首发地址https://www.infoq.cn/article/0AXykmqvf5lHZsEQtjBp
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券