2021 年 9 月 22 日 – 甲骨文日前正式发布 java 17，这是备受欢迎的编程语言和开发平台新推出的版本。java 17 提供了数千种性能、稳定性和安全性更新，以及 14 个 jep（jdk enhancement proposal，即 jdk 增强建议）来进一步优化 java 语言和平台，从而帮助开发人员提高工作效率。
甲骨文每六个月如约发布新版本的 java，而 java 17 是最新发布的 长期支持 (long-term support, lts) 版本。此版本是甲骨文公司的工程师与全球 java 开发人员社区的成员通过 openjdk 社区 和 jcp (java community process) 共同合作的成果。自三年前发布 jdk 11 lts 发行版后，甲骨文已经实现了超过 70 项 jep。
提供更简单的许可证
甲骨文将从 oracle jdk 17 发行版开始提供免费使用的许可证，直到下一个 lts 版本推出一年后。甲骨文也将延续自 2017 年以来的做法，继续根据开源通用公共许可证 (gpl) 发布 oracle openjdk 发行版。
增强对客户的长期支持
甲骨文与 java 开发人员社区和 jcp 合力优化 lts 计划，如果组织希望迁移到较新的 java lts 版本，他们将拥有更大的灵活性，并且可以更好地掌控时间。下一个 lts 版本将会是 java 21，于 2023 年 9 月推出，lts 版本的发布周期将从现有的三年缩短至两年。
oracle lts 和 java se 订阅的客户可以按自身计划迁移到 java 17。甲骨文将为客户提供 java 17 的安全、性能和错误修复更新，至少到 2029 年 9 月。
甲骨文 java 平台组开发副总裁 georges saab 表示：“在过去的三年里，许多开发人员都很喜欢这些新功能，我们看到生态系统真正适应了每六个月一次的发布节奏。java 开发人员目前面临的一大挑战是，他们的组织只允许使用最新的 lts 版本。现在，lts 版本将改为每两年发布一次，组织较为保守的开发人员也可以选择和访问他们喜欢和想要使用的功能。”
idc 软件开发研究副总裁 arnal dayaratna 表示：“甲骨文正在做出改变，不仅将长期支持版本的发布周期改为两年，同时新推出许可证也更宽松，延长了生产环境的 oracle jdk 免费使用期限，让 java 社区获益无穷。因此，组织可以更灵活地管理云、本地和混合环境中复杂的现代应用程序开发和部署。”
加快 java 在云中的采用
java 是一个成功的开发平台，以满足开发人员不断变化的需求为目标而持续进行创新。为了加速 java 在云中的采用，甲骨文最近推出了 oracle java 管理服务 (oracle java management service)，这是一项新的 oracle 云基础设施 (oci) 原生服务，可帮助组织在本地或任何云端管理 java 运行时和应用程序。
oracle java 管理服务能够帮助客户了解整个企业中的java部署，这涵盖了安装在企业环境中的所有 java 版本，即在开发和生产中运行的 java 版本。oracle java 管理服务能够突出显示任何未计划运行的 java 应用，并检查所有已安装的 java 版本是否安装了最新的安全补丁，确保版本时时更新。
jdk 17 增加了新的语言增强功能，对库进行更新，支持新款 apple 计算机，移除和弃用旧功能，并且确保用户编写的 java 代码在未来的 jdk 版本中可以继续正常工作。此外，jdk 17 还提供语言功能预览版和孵化阶段的 api，以收集来自 java 社区的反馈。更新内容包括：
java 语言增强功能
jep 409：密封类 — 密封类和接口限制其他类或接口扩展或实现它们。此增强功能是project amber的又一项改进，旨在通过发展 java 语言来提高开发人员的生产力。
对库进行更新和优化
jep 306：恢复始终严格的浮点语义 — java 编程语言和 java 虚拟机最初只有严格的浮点语义，从 java 1.2 开始，为了适应当时硬件架构的限制，默认允许这些严格语义中的细微变化。现在不再需要这些变化，已在 jep 306 删除。
jep 356：增强型伪随机数生成器 — 增加伪随机数生成器 (prng) 的新接口类型和实现方法，提高了不同 prng 的互操作性，并且易于根据需求请求算法，而不是对特定实现进行硬编码。
jep 382：新的 macos 渲染管道 — 通过使用新的 apple metal api 为 macos 实现 java 2d 渲染管道，减少了 jdk 对已弃用的 apple opengl api 的依赖。
支持新平台
jep 391：macos aarch64 端口 — 将 jdk 移植到 macos/aarch64 平台，java 应用可以原生运行于基于 arm 64 的新 apple silicon 计算机。
移除和弃用
jep 398：弃用即将移除的 applet api — 所有 web 浏览器供应商正在计划或已经停止支持 java 浏览器插件。applet api 已于 2017 年 9 月在 java 9 中弃用，但并未移除。
jep 407：移除 rmi 激活 — 移除远程方法调用 (rmi) 激活机制，保留其他 rmi。
jep 410：移除实验性的 aot 和 jit 编译器 — 基于 java 的提前 (aot) 和即时 (jit) 实验性编译器并未被广泛采用。作为一个选择性功能，aot 和 jit 编译器已在 jdk 16 中移除，本次在 jdk 源代码中移除。
jep 411：弃用即将删除的安全管理器 — 从 java 1.0 开始，安全管理器一直都不是保护客户端 java 代码的主要手段，也很少用于保护服务器端代码。在未来的版本中会移除安全管理器，以消除大量维护负担，让 java 平台能够向前发展。
面向未来的java程序
jep 403：jdk 内部强封装 — 用户再也不能像在 jdk 9 到 jdk 16 中一样通过单个命令行选项来放宽对内部元素的强封装。用户仍然可以访问现有的内部 api ，但需要以命令行参数形式或 jar 文件清单属性进行枚举，且每个包应该放宽封装。此更改将导致应用程序更安全，并减少对非标准、内部 jdk 实现细节的依赖。
未来jdk发行版的预览版和孵化器
jep 406：switch 模式匹配（预览版）— 允许switch表达式针对多个模式进行测试，每个模式都有特定的操作，从而简洁、安全地表达面向数据的复杂查询。
jep 412：外部函数和内存 api（孵化阶段）— 改进 jdk 14 和 jdk 15 中引入的孵化 api，让 java 程序与 java 运行时之外的代码和数据进行互操作。通过有效调用外部函数（即 jvm 之外的代码），以及安全地访问外部内存，这些 api 可以调用本地库和处理本地数据，并且不受 java 本机接口 (java native interface, jni) 的脆弱性和复杂性影响。这些 api 正在project panama中开发，目的是改进java 和非java 代码之间的交互性。
jep 414:矢量 api（二次孵化阶段）— 允许以一种在运行时，可靠地编译为支持的 cpu 架构上的最佳向量指令的方式表达向量计算，从而实现优于等效标量计算的性能。