《Java 演进之路》系列 · 第 13 篇

密封类落地，LTS 安心：JDK 17 的稳重进化

“当开发者能将那些曾令人心动的预览特性，毫无顾虑地用于生产环境时，语言的演进才真正完成了它的闭环。”

2021年9月，JDK 17正式发布。它是个长期支持版本（LTS），注定要接替JDK 8、JDK 11的班，成为未来好几年大家的主力。如果说JDK 16是个敢想敢干的“尝鲜者”，那JDK 17就是个靠谱踏实的“交付者”。它没整那些花里胡哨的新玩意儿，而是把过去几个版本里大家公认的好东西，正式焊死在了语言里，还顺手把平台的安全墙给加固了。说白了，它的任务就一个：给未来几年的Java开发，铺一条又稳又现代的路。

📌 JDK 17 官方特性总览

JDK 17的所有新特性都是基于 JSR 392（《Java SE 17 发布规范》） 来搞的。作为LTS，它的思路特别务实：

• • 一是“扶正”：把Records、模式匹配、密封类这些经过大家检验的好东西，从“预览版”转成“正式工”。
• • 二是“加固”：比如强封装这种，就是告诉咱们：“别老想着走后门了，好好写代码！”
• • 三是“探索”：FFM API、Vector API这些还在孵化器里，算是给Java的未来探探路。

每一项改动，要么让你写代码更爽，要么让平台跑得更稳，这才是LTS该干的事。

1. 密封类（正式特性，JEP 409）

在JDK 15/16那会儿，我就偷偷在玩密封类（Sealed Classes）了。用来定义一些状态机或者简单的数据模型，简直不要太爽。但每次用都得加上--enable-preview，心里总有点发毛，生怕哪天语法一变，我这代码就废了。

JDK 17终于让它转正了！现在，我可以光明正大地写：

// 定义一个密封的订单状态接口
public sealed interface OrderStatus 
    permits Created, Paid, Shipped {}

final class Created implements OrderStatus {}
final class Paid implements OrderStatus {}
final class Shipped implements OrderStatus {}

最爽的是啥？配合switch表达式，编译器能帮你检查是不是把所有情况都覆盖了！再也不用担心半夜被线上漏掉一个状态的bug叫醒。而且，看到这个sealed关键字，你就知道这个类型体系是封闭的，代码本身就是最好的文档。

不过也有小坑：子类必须和父类在同一个模块里，不然编译直接报错。一开始我还以为是自己写错了，查了半天才发现是这规矩。

📌 意义：密封类正式化，对我来说不是多了个语法糖，而是少了一个巨大的运行时隐患。它让我能用一种既安全又声明式的方式去建模，写出来的代码，连我自己半年后回头看都能秒懂。

2. Foreign Function & Memory API（孵化器，JEP 412）

坦白讲，这个特性我到现在都没在正经项目里用过，光看名字就觉得头大。

官方说它能安全高效地调C/C++代码，还能管native内存，目标是干掉JNI。听起来很牛，对吧？我也心动了，拉了个小例子想试试。

结果……API设计得太灵活了，各种MemorySegment、MethodHandle，看得我眼花缭乱。折腾了快一个小时，感觉还不如直接用Runtime.exec()来得快。对我这种偶尔调个系统命令的人来说，这玩意儿暂时就是个“屠龙技”。

不过我能感觉到，这是Java在向底层世界伸出的橄榄枝。虽然我现在用不上，但知道它在那儿，心里还挺踏实的。

📌 意义：FFM API现在还是个“宝宝”，但它代表了Java未来的野心——不再只是应用层的老好人，也要能跟操作系统、硬件直接对话。这步棋，走得长远。

3. Vector API（第二孵化器，JEP 414）

还记得我在JDK 16里试Vector API，在M1 Mac上直接翻车的事吗？当时那个郁闷啊！

JDK 17说对ARM SVE有初步支持了，我心想：“这次总该行了吧？”立马又把之前的图像处理脚本拿出来跑。

结果你猜怎么着？还是报错！UnsupportedOperationException，熟悉的配方，熟悉的味道。查了半天文档，发现我的M1芯片还不在支持列表里，真是哭笑不得。

不过在Intel机器上跑，速度是真的快，感觉CPU一次能干好多活，而不是一个一个来。虽然现在用不上，但至少让我看到，Java没放弃在高性能计算领域争一席之地。

📌 意义：Vector API就像是Java给自己埋下的一个彩蛋。现在可能只有少数人在挖，但万一哪天挖出个宝藏，整个生态都会受益。这种面向未来的投入，值得点赞。

4. 强封装 JDK 内部（JEP 403）

这个真不是新功能，而是一个“大招”，也是我升级到JDK 17时踩的最大一个坑。

简单说，就是JDK 17默认把内部包（比如sun.misc.Unsafe）的“后门”全给焊死了。以前靠反射随便捅的日子，一去不复返了。

我把一个跑了好几年的老数据同步脚本迁过来，启动直接挂了，报了一堆InaccessibleObjectException。我当时就懵了：“我代码一行没动啊！” 折腾了快一个小时，才想起来要加--add-opens参数。

虽然有点烦，但想想也是好事。这逼着我们别再依赖那些不稳定的内部API，得写更规范、更面向未来的代码。长痛不如短痛嘛。

📌 意义：JEP 403是Java平台走向成熟的“成人礼”。它牺牲了一点点“灵活性”，换来了巨大的“稳定性”和“安全性”。以后升级JDK，再也不用担心因为用了内部API而一夜回到解放前了。

🧩 为什么关注 JDK 17？

• • LTS 基石：它是未来数年企业级应用的首选版本，提供了长期的稳定性和支持。
• • 特性集大成：它把JDK 14-16里最成功的语言特性（Records, 模式匹配, 密封类）全部打包进了LTS，让我们可以放心大胆地用。
• • 安全加固：强封装这种措施，虽然升级时有点小麻烦，但长远来看，是给整个Java生态“排雷”。
• • 未来可期：FFM API和Vector API的持续孵化，说明Java没躺在功劳簿上睡大觉，还在努力拓宽自己的边界。

🧱 其他重要平台增强

• • 弃用 Security Manager (JEP 411)：这个古老的安全模型终于要退休了，世界清净了。
• • 新的 macOS 渲染管道 (JEP 382)：用Apple Metal替代了老旧的OpenGL，Mac用户应该能感觉到图形性能更流畅了。
• • 上下文特定的反序列化过滤器 (JEP 415)：能给反序列化加个动态“安检门”，防止坏人塞恶意对象进来，安全加分项。

✅ 总结

JDK 17通过JSR 392，干了两件大事：一是把密封类这些好东西正式落地，让我们写代码更安全、更简洁；二是用强封装加固了平台，让未来的升级之路更平坦。它没有去追求那些宏大的、颠覆性的变革，而是精准地完成了LTS版本的核心使命——把可能性，变成确定性。对我来说，JDK 17不是一个需要仰望的里程碑，而是一个可以安心托付的伙伴。这就够了。

📢 延伸阅读建议

• • JSR 392: Java SE 17 规范[1]
• • OpenJDK JDK 17 官方页面[2]
• • JEP 409: Sealed Classes[3]
• • JEP 412: Foreign Function & Memory API (Incubator)[4]
• • JEP 414: Vector API (Second Incubator)[5]
• • JEP 403: Strongly Encapsulate JDK Internals[6]

引用链接

[1] JSR 392: Java SE 17 规范: https://www.jcp.org/en/jsr/detail?id=392 [2] OpenJDK JDK 17 官方页面: https://openjdk.org/projects/jdk/17/ [3] JEP 409: Sealed Classes: https://openjdk.org/jeps/409 [4] JEP 412: Foreign Function & Memory API (Incubator): https://openjdk.org/jeps/412 [5] JEP 414: Vector API (Second Incubator): https://openjdk.org/jeps/414 [6] JEP 403: Strongly Encapsulate JDK Internals: https://openjdk.org/jeps/403