Pattern Matching for instanceof instanceof的模式匹配

instanceof的模式匹配从JDK14进入孵化，到JDK16正式转正。

---

Records

records从JDK14引入预览版到JDK16转正。

---

Elastic Metaspace

弹性的元空间，可以帮助 HotSpot 虚拟机，将元空间中未使用的 class 元数据内存更及时地返回给操作系统，以减少元空间的内存占用空间。

---

ZGC: Concurrent Thread-Stack Processing

这个版本则是为了让 ZGC 支持并发栈处理，解决了最后一个重大瓶颈，把 ZGC 中的线程栈处理从安全点移到了并发阶段。并且还提供了一种机制，使得其他 HotSpot 子系统可以通过该机制延迟处理线程栈。

 

 

---

Strongly Encapsulate JDK Internals by Default默认对 JDK 内部进行强封装

JDK 内部默认强封装，JDK 16 开始对 JDK 内部大部分元素默认进行强封装限制对它们的访问，sun.misc.Unsafe 之类的关键内部 API 除外。鼓励开发人员从直接使用内部元素逐渐迁移为使用标准API，这样开发人员和最终用户都可以轻松地升级到 Java 的未来版本。

这个特性是从JDK9模块化功能推出了后就一直存在，为了给大家一个缓冲时间迁移，JDK开发人员故意选择在运行时不强封装JDK 8中存在的包的内容。因此，类路径上的库和应用程序代码可以继续使用反射来访问java的非公共元素。17年发布到JDK16发布过去三年时间，大部分库已经完成了迁移工作，所以JDK默认进行强封装了。不过可以通过参数--illegal-access=permit关闭强封装。

在Java 9中，我们通过利用模块来限制对JDK内部元素的访问，从而提高了JDK的安全性和可维护性。模块提供了强封装，这意味着

• 模块外部的代码只能访问该模块导出的包的公共和受保护元素。
• protected 修饰的元素只能由定义它的类已经它的子类访问。

强封装适用于编译时和运行时，包括已编译代码试图在运行时通过反射访问元素时。导出包的非公共元素和未导出包的所有元素都被称为是强封装的。

---

其他

Packaging Tool：新的打包工具转正。

Foreign-Memory Access API (Third Incubator)

Sealed Classes (Second Preview)

用于Java开发机器学习和深度学习的Vector API进入孵化