苏州2018年JAVA发展前景​

在过去的 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）垃圾回收器，只是目前还没有可用的替代品。

比较有意思的变更或许是 JEP 286，增强的本地变量类型推断可以让开发者免去很多变量申明模板代码。也就是说，在下一个版本中，下面的变量声明是合法的：

var list = new ArrayList<String>();  // infers ArrayList<String>var stream = list.stream();          // infers Stream<String>

这种语法只限于初始化过的本地变量和 for 循环中的本地变量。

它其实是个语法糖，在语义上并没有任何变化。不过，该特性有可能在 Java 开发者当中引起热议。其他三个变更都将在性能方面带来一些影响。

JEP 307 解决了 G1 垃圾回收器的一个问题——截止到 Java 9，G1 的 Full GC 采用的是单线程算法。也就是说，G1 在发生 Full GC 时会严重影响性能。JEP 307 的目的就是要采用并行 GC 算法，在发生 Full GC 时可以使用多个线程进行并行回收。

JEP 310 对类数据共享（CDS）进行了扩展，JVM 可以将一些类记录到一个共享的压缩文件里，在 JVM 下一次启动时可以将这个文件映射到 JVM 进程，以此来减少启动时间。该文件也可以在多个 JVM 间共享，在同一个机器上运行多个 JVM 时，这样做可以减少内存占用。

该功能在 Java 5 中就已存在，但截止到 Java 9，该功能只允许 bootstrap 类加载器加载压缩的类。JEP 310 的目的是扩展该功能，让应用程序和自定义类加载器也能加载压缩的类。该特性目前仅在 Oracle JDK 中可用，OpenJDK 并不包含该特性。

JEP 计划将该特性从 Oracle 私有仓库中迁移到公共仓库，从 Java 10 往后，常规版本（非 LTS）将会使用 OpenJDK 的二进制包。此举表明有用户正在使用该特性，所以需要在 OpenJDK 中也支持该特性。

JEP 312 旨在改进虚拟机性能，在应用程序线程上调用回调不再需要执行全局虚拟机安全点操作，这意味着 JVM 可以停止单个线程。一些底层小改进包括：

• 降低堆栈跟踪取样所带来的影响（如进行 profiling）。

• 减少信号依赖以获得更好的堆栈取样。

• **停止单独线程改进偏向锁。

• 从 JVM 移除了一些内存屏障。

从整体来看，Java 10 似乎并没有包含重大新特性或性能改进。这是可以理解的，毕竟这是新发布周期下的**个版本。