自Java 9开始每6月将会有一个新的Java版本发布出来，这个决定背后的考量是Java在Cloud Native时代竞争力逐渐减弱，如果仍然按照以前每3~4年才发一个版本的节奏，一大波开发者可能会另寻出路了，毕竟这几年Python,Go还有JavaScript发展的都太猛了。按照这项规则，Java 17将在2021年9发布 (Java16于2021年3月21日发布)。而且最重要的是Java 17将是Java 9以来的集大成者，其影响力将大大超过Java 11，在最近3年内流行程度会逐步追上Java 8并取代 Java 8成为最受欢迎的Java 版本。Java 11是 Java 9以来第一个长生命周期支持版本（LTS），然而 Java 11还并未在生产环境中得到太多的使用，尽管它已经非常不错，经过Java 9到 Java 16这么多版本的酝酿和熏陶，大多数开发者逐渐接受了模块化JDK这一革命性变化，并且开发了根据这项新技术对过去的项目做了相关的修改和适配，到目前为止相当多的开源框架已经完全兼容Java 11。 从技术上讲Java 17对 Java 11的兼容是顺滑的，因此这些框架只要兼容了Java11理论上兼容Java 17是没有问题的。 为什么 Java 17会这么重要 ？ 是因为它是另外一个长生命周期版本，而且自Java 11以来积累了非常多的新特性，尤其是ZGC，无论堆内存是1个G还是1个T，它能够在10毫秒量级内完成垃圾回收动作，而G1最多可能会耗时1秒，这是两个数量级的差别。
ZGC 吞吐量与G1相仿但延迟处理要更强
ZGC大大提升了垃圾回收的确定性以及可预测性
那么除了ZGC，Java 17还有那些得期待的功能增强(JEP, Java Enhancement Proposal)呢?
JEP 398 ，Applet API将会被标记为删除Applet API将会被标记为删除，意味着 JDK18中它将被删除。这个影响倒不是很大因为Applet 这项技术早已淡出主流技术栈，由于安全原因主要的浏览器已经不支持NPAPI(Netscape Plugin Application Programming Interface)这项技术，导致Adobe Flash，Java Applet等基于NPAPI的技术无法使用。
JEP 391: macOS/AArch64 Port2020年Apple宣布了为期2年的从X86 CPU转换为 Apple Silicon的计划，所有的Apple设备将主要使用Apple 自家设计CPU， JEP 391目的是将 JDK移植到这种新的架构上去，Java构建者希望通过使用条件编译来重用来自这些移植版的现有AArch64代码，就像JDK移植版的常规做法一样，以适应低级约定方面的差异，比如应用程序二进制接口和保留的处理器寄存器集。针对MacOS/AArch64的更改可能会破坏现有的Linux/AArch64移植版、Windows/AArch64移植版和MacOS/x64移植版，但是可以通过预集成测试来降低这种风险。
JEP 356: 增强版伪随机数生成器JEP 356 目标是提供一种性能更好的伪随机数生成器，并且能够在不同的随机数生成算法中进行切换，去掉各种算法中重复代码，提供一种更好的流式编程支持，当然还需要保证兼容 java.util.Random行为
JEP 382: 全新macOS 渲染管道JEP 3382 实现了全新的MacOS渲染管道，使用Apple Metal API以替代使用被弃用的OpenGL API的现有管道。该提议旨在为使用MacOS Metal框架的Java 2D API提供一条功能全面的渲染管道，万一苹果从未来版本的MacOS中删除OpenGL API，可以准备就绪。该管道旨在功能上与现有的OpenGL管道相当，在某些应用程序和基准测试中的性能一样好或更好。将创建适合当前Java 2D模型的干净架构。管道将与OpenGL管道共存，直到过时。提案的目的并不是添加任何新的Java或JDK API。
除此以外，JDK16中正在孵化的项目包括Vector (硬件向量计算加速) 和 Foreign Linker API(纯Java 访问native代码，替换JNI) 也有可能在JDK 17(LTS版本) 中升级为正式API
