期待已久的Java 9今日发布_最新动态_新闻资讯_程序员俱乐部

　　英文原文：Long Awaited Java 9.0 Releasing This Week

　　人们期待已久的 Java SE 9.0 将在2017 年 9 月 21 日发布，它会带来一些重要的变化。

　　JDK 9 的核心变化就是引入了一种新的 Java 编程组件，也就是模块，按照 Oracle 的说法，它是一个可命名的、自描述的代码和数据集合。模块技术的核心目标是减少 Java 应用和 Java 核心运行时环境的大小与复杂性。为此，JDK 本身进行了模块化，Oracle 希望通过这种方式提升性能、安全性和可维护性。

　　为了支持 Java 9 的模块，引入一种新的模块化 JAR 文件形式，按照这种形式会在其根目录中包含一个 module-info.class 文件。Oracle 同时提供了工具，允许我们组合和优化一组模块，形成自定义的运行时镜像（image），这样的镜像不必将整个 Java 运行时包含进来。模块化所带来的其他变化包括从 Java 运行时镜像中移除了 rt.jar 和 tools.jar。

　　InfoQ 与 Ben Evans 进行了交流，以了解他对 Java 9.0 模块系统的看法，他是 Java 社区进程（JCP）执行委员会的成员。

Evans：我认为最急需重构的应用恰好就是最适合进行模块化的应用。如果你已经备受 Lava Flow / God Class / Stovepipe System 地狱的折磨，而且你的利益相关方明确知道这一点，那么你可能更容易说服他们进行一次完整的底层重构，通过渐进式的努力形成一个完成的模块解决方案（而不是简单重构并迁移至 Java 8）是值得去做的。

　　Oracle 宣布 Java 8 会是一个长期支持的发布版本，会一直支持到 2022 年，因此 Evans 认为很多的应用将会停留在 Java 8 上，根本不会升级到 Java 9。Evans 补充说，有些应用可能会让开发和构建工具链使用 Java 8 版本，而在生产环境使用 Java 9 的运行时。

对特定类型的应用来说，这是很有帮助的。例如，我曾经见到有的电子商务网站具有非常大的堆空间，其中包含了大约 40G 的字符串数据。Java 9 的 ompact Strings 技术能够将这种类型的内存使用减半。这反过来又会对 GC 的性能带来积极的影响。对于有些应用来说（这可能就包括大型的 Solr 安装环境及类似场景），单单这一项收益就值得将运行时升级到 Java 9。

　　Java 9 使用 G1作为默认的垃圾收集器，替代了之前默认使用的 Parallel GC。Evans 对这项变化的评论：

这项变更是很重要的，因为相对于 Parallel 来说，G1 会在应用线程上做更多的事情，而 Parallel 几乎没有在应用线程上做任何事情，它基本上完全依赖 GC 线程完成所有的内存管理。这意味着切换到 G1 将会为应用线程带来额外的工作，从而直接影响到应用的性能。

在很多（甚至可以说大多数）场景中，这种额外的性能损耗都不是什么问题。但是，在这方面，我确实也曾经见过从 Parallel 切换到 G1 时，有一定比例的工作负载会引起性能的下降。对于这些应用来说，这种性能下降是无法接受的，所以他们无法切换至 G1 收集器。随着 G1 成为默认的收集器，这将会影响到升级至 Java 9 的每个应用。

　　对于大型的代码库是否需要重构为模块的形式，InfoQ 询问了 Martijn Verburg 的意见，他是 JClarity 的 CEO，也是伦敦 Java 用户组（Java User Group）的联合组织者。

Verburg：需要这样做，另外，我还希望你要处理的大型代码库已经按照一定的模块化结构语义进行了拆分，不管你采用的是 OSGi、Maven 模块、JBoss 模块，还是采用简单的内部规则，将包和接口的结构划分出清晰的边界都可以。

　　Verburg 给出了一些通用的模块化建议，并且指出了开发人员在采用 Java 9 模块系统时，需要注意的一些事情：

• 阅读 Paul 和 Sander 的图书“Java 9 modularity”：它是本权威指南，提到了所有需要注意的地方，阐述了模块、包以及 JAR 之间如何运行的关联关系；
• 在模块边界的地方，使用定义良好的接口并且针对这些接口编程；
• 不要拆分包（split package），也就是说一个包不要分散到两个模块中。Adopt OpenJDK 有个探测工具，我们可以用它来探测已有的代码；
• 确保不要存在循环依赖（Jigsaw 不允许这样）；
• 模块在源码的布局上与我们已习惯的方式有所不同，需要确保构建工具能够进行对应的处理；
• Jigsaw 不支持多版本。

　　按照 Verburg 的说法，核心要点在于处理循环依赖、拆分包的问题，并确保针对接口进行编码。在尝试使用 Jigsaw 模块化重构之前，针对已有的代码库，这些工作需要预先完成。他还澄清了一个误解，那就是只有模块化的应用才能在 Java 9 上运行。

由于误解，在这方面有一种 FUD（恐惧、不确定和怀疑）情绪，有人误认为在 Java 9 上运行的必须是模块化的应用。事实并非如此，我们可以将已有的基于类路径的应用直接在 Java 9 上运行。这里会有一些新的安全限制，因此我们需要设置一些特定的运行时标记（除非你重构代码，使用更安全的方式来访问 Java 的内部资源），即便如此，默认的行为也只是警告，而不是完全阻止我们（Java 10 的限制会更严格）。

　　Verburg 认为 Jigsaw 会是一个基石，会让 Java 的演进更快，这要归功于 Mark Reinhold、Alan Bateman、Mandy Chung 以及 Jigsaw 团队的其他成员多年来不知疲倦的工作，正是他们的努力使这一切得以实现。

　　Java 9 还引入了 jshell 工具。这个命令行环境为 Java 平台带来了读入-求值-打印-循环（Read-Eval-Print-Loop，REPL）功能。它的目的在于以即时结果和反馈的形式，简化原型的实现并帮助我们探索语言在编码时的可选项。

　　Verburg 和 Evans 看到 Java 9 中包含了 jShell 都非常兴奋，但令他们失望的是，HTTP/2 只是作为 Java 9 的一个孵化模块（incubator module）提供的。鉴于社区对这项特性的兴趣和提供的帮助，Evans 认为 Oracle 应该投入足够的工程资源，将 HTTP/2 交付为 GA 版本。

　　JDK 9 完整的变更列表可以在 Oracle 的站点上查阅。Oracle 宣布会按照每六个月一次的节奏进行发布，意味着 Java 9 是最后一次“keystone”特性驱动的版本发布，这反映出了 Oracle 目前管理 Java 的特点。Java 下一阶段的演化将会按照更短的发布周期并且会按照更加面向特性的方式来发布。Java 是否依然能够在服务端技术中占据领导者地位尚有待观察。