在过去的 2017 年中，Java 世界中发生了许多前所未有的变化，其部分原因在于 Java 9 的推出，尽管它推后了近一年的时间。

然而，随着时间的推移人们可能会发现，推出 Java 9 版本的意义，远没有随该新版本一并推出的 Java 版本发布周期变更为每六个月一次的意义更为重大。Java 版本发布周期的变更，意味着在 2018 年将会推出两个 Java 新版本，而非一个。

2018 年将推出的第一个新版本称为 Java 10，第二个新版本是 Java 11。虽然这一命名方案与现有命名看上去毫无二致，但是新版本只有经过重大公开辩论并达成最终共识后，才能得以推出。

鉴于新版本的推出将切换到这样一种严格按时间点的节奏，预计这将使每个新版本中发布的 Java 特性，比迄今为止所能看到的范围更为缩减。就 Java 10 而言，这意味着新特征的数量将相当之少。

InfoQ 先前曾报道了 Java 10 中的主要特性，一会也会再说。此后，该版本中添加特性的仅是一些细微的（Additional Unicode Extensions）、清理性质的（移除了原生的头部生成工具，提供默认的 CA 根证书）、实验性质的（基于 Java 的 JIT 编译器 Graal），或是当前为利基性质的 (对异构内存架构的支持)。

至于 Java 11 中考虑了哪些功能，目前更是云山雾罩。我们只能确认下列几个功能在考虑范围内：

• Epsilon。一种对 Null 垃圾回收算法的参考实现。

• Dynamic Class File Constants 。一种主要针对软件库编写人员及使用动态特性 invokedynamic 高级开发人员的平台特性。

• 运行时追踪 JIT 编译事件。

一旦发布日期临近，该特性列表肯定会被填满。但是值得注意的是，列表中目前尚未提及 Java 值类型。这也许并不出乎意料，因为实现值类型需要对 Java 语言和运行时做重大更改，并对 Java 类型系统（包括泛型）做完全重构。

尽管当前原型已工作，但是距特性交付尚有很长的路要走。当前状态只适用于低级别的平台开发人员，以及那些习惯于使用基于反射（reflective）或 MethodHandle 工具的开发人员。看上去令人不可思议的是，尽管值类型将作为 Java 11 的一部分发布，但是 Oracle 依然尚未对该特性预期于何时发布公开发表任何评论。

但是，如果值类型并未作为 Java 11 的一部分提供，这将会产生连锁反应。包含值类型的首个长期支持（LTS）版本将不会在 2021 年 9 月前发布。

在撰写本文时，我们尚不清楚已在提案中的数据类（data classes）特性是否会出现在 Java 11 中。正如 Java 语言架构师 Brian Goetz 所介绍的：

数据类将用于解决类的表示与 API 合约间存在的复杂间接关系。通过使用数据类，编译器可以填入一些常规类成员。

数据类提案与 Scala 的 Case 类具有一些相似之处。但是 Goetz 明确指出，数据类的设计空间中还存在一些可能的变动，该特性的整体语义含义要比目前我们能看到的更为深入。目前的数据类概念是与同处于开发过程中的模式匹配特性深度关联在一起的。但是，这两个特性可能会在不同的版本中提供。

与上面两个特性都相关的是，未来可能对 Switch 形式做改进。Switch 语句块将可作为表达式或声明使用。

该特性相对较小，有望在 Java 11 中交付，即便数据类或模式匹配特性尚未实现。但目前情况看，该特性仍然是一个 JEP 草案。

最终将于 9 月发布的版本，其特性完成日期是 2018 年 6 月。因此，在 Java 11 的整体形态浮出水面之前，我们必须再等待数月时间。

说回到 Java 10，它的新特性还在确认当中，所以从现在到 GA 版中间还是有可能加入重大的变更。不管怎样，在这四个月里，开发者还是可以期待一些新的特性能够被添加到 Java 10 中。

新的特性和增强一般通过 Java Enhancement Process（JEP）或 Java Community Process 标准请求（JSR）进行跟踪。因为 Java 10 的时间线较短，范围也相对较小，所以 Java 10 的变更将通过 JEP 进行跟踪。

有望被包含在 Java 10 中的特性是那些已经处于 Targeted 或 Proposed 状态的 JEP，它们包括：

• 286：本地变量类型推断

• 296：统一 JDK 仓库

• 304：垃圾回收器接口

• 307：G1 的并行 Full GC

• 310：应用程序类数据共享

• 312：ThreadLocal 握手机制

JEP 296 是一次纯粹的清理工作，而 JEP 304 加强了不同垃圾回收器的代码隔离，并为垃圾回收器引入更简洁的接口。

JEP 304 意味着厂商可以更自由地选择特定的 GC 算法来构建 JDK，因为现在有多种处于开发当中的 GC，如 Shenandoah、ZGC 和 Epsilon，在未来可以使用这些 GC 算法。社区也在努力弃用甚至移除 Concurrent Mark Sweep（CMS）垃圾回收器，只是目前还没有可用的替代品。