无视社区担忧，JPMS（Jigsaw）将被提交公开预览

Oracle Java 平台组首席架构师 Mark Reinhold 证实，虽然 IBM 和 RedHat公开表达了担忧，但通常称为 Jigsaw 的 Java 模块将被提交公开预览。在 OpenJDK 邮件列表的一个话题中，他写道：

关于转到公开预览，我们在 EG 内还没有达成共识。这只是因为有部分成员仍坚持认为，我们必须实现既没有在最初提交的 JSR 中提到又没有在协商一致的需求中记录的目标。然而，进入下一阶段符合更广泛的 Java 生态系统的最佳利益，那样，我们可以兑现我们实际承诺的目标。因此，尽管没有达成一致，我还是提交了公开预览规范。

作为回应，来自 IBM 的 Tim Ellison 提供了一些其他的背景信息，说明为什么 IBM 将投反对票，他用一条非常长的消息概述了自己和其他人的担忧。

虽然我理解继续推进这个进程的愿望，但我认为，听取 EG 的集体智慧并尊重他们的意见是有价值的。它不应该让人如此震惊，执行委员会代表向 EG 成员发表讲话，让他们就规范是否已经准备好进入下一阶段支持自己的立场。

有必要读一下整个评论，下面是他列出的其中一部分技术问题：

隔离不充分——模块的非导出（私有）程序包应该严格实现细节。JPMS 默认每个层一个单独的类加载器，这意味着，当同时加载时，私有程序包可能导致出人意料的冲突。

模块名称自动化——模块的依赖是通过模块名表示的，因此，提供一个标准 API 的实现者都必须使用相同的模块名。然而，模块名称自动化的基础是 jar 文件名，而它们是实现细节。我们需要确定，模块名是一组 API 还是一个具体实现的简写。

访问限制会破坏执行反射的程序库——模块必须事先知道是否向反射开放，并且知道反射者的模块名。这会破坏依赖注入，诸如此类。

对于最后一点，我们和目前处于预览状态的 CDI 2.0 的规范负责人 Antoine Sabot-Durand 进行了交流。当然，作为 RetHat 的员工，他当然站在 RedHat 和 IBM 的立场上，他表示：

Jigsaw 应该仅对 CDI 规范产生有限的影响，但在具体实现时，影响将是巨大的（反射部分、代理处理、类加载）。按照我的理解，Java 9 提供了一个新的 Layer API，那可以解决部分类加载和可见性问题，但文档中缺少示例，切换到 Layers 可能意味着巨大的工作量，而且没有绝对的保障。

不过，Spring Framework 项目负责人 Juergen Hoeller 告诉我们，Spring Framework 5.0 RC1 或 4.3.8 依赖于最新的 JDK 9 build 167：

• 开放模块不必知道反射者的名称；它们可以只是选择性地将自己暴露给特定的模块。应用程序模块很容易声明，本身或具体的程序包向其他任何模块开放。在我看来，这很方便，当然不是 Jigsaw 的设计缺陷。
• 即使不公开声明，导出类型的反射也可以很好地工作；只不过是操作一个非公有的字段，或者调用一个最终会失败的非公有方法。也就是说，我们可以通过内省找出任何导出类的注解……只要我们在公有构造函数 / 方法上找到这样的注解，那么在任何情况下，我们都可以执行依赖注入——即使没有公开声明。
• 为了处理类的“非公有”成员，模块其实需要将自己或者至少是受影响的程序包声明为公开。这会影响私有字段注入、到私有字段的数据绑定以及 Spring 将 CGLIB 用于 @Configuration 类和非接口 AOP 代理……这就是为什么我们建议（但不是必须）使用 Spring 时公开声明。总之，将当前的 Spring Framework jar 文件用作 Jigsaw 模块路径的“自动化模块”是一种开箱即用的顺畅体验，无需为此自定义命令行标识。应用程序可能会在它们自己的模块描述符中遵循 Jigsaw 的自动化模块命名方法，声明对“spring.context”等的模块依赖。只要这种基于 jar 文件的模块名目前没有问题（我非常喜欢它对 Spring jar 和常见第三方库的命名），基于 Spring 的应用程序就已经可以选择一种不错的 Jigsaw 设置体验了。

尽管如此，Hoeller 也指出，他希望大多数基于 Spring 的应用程序留在类路径上，即使升级到 JDK 9 时也是如此，这主要是为了更方便地集成类似 Hibernate 这样的第三方库。

在 Java 社区进程执行委员会的 25 个成员中，有三分之二采用了新的 Java 标准。InfoQ 和另外一名专家组成员、来自 Hazelcast 的 Christoph Engelbert 进行了交流，他表示，Hazelcast 也可能投反对票：

我认为情况相当复杂，因为赞成者和反对者双方可能在不同的点上是正确的。Mark Reinhold 提到的其中一个问题是，某些特性起初是不必要的。虽然这很可能是对的，但之所以一定要实现，是因为 Java 世界的开发者们不想在今后几年的开发中作出改变。显然，那也是不正确的。

一般来说，在 Hazelcast，我们看到，JSR376 专家组（EG）没有达成一致，规范负责人的处理方式也很值得怀疑。我们还没有投票，但根据和社区及 EG 成员的讨论，我们可能会投“反对票”。

不要误会我，我是说，Jigsaw 是一个重要的特性，但它需要更多的时间或者换种方式来停止它。使用“大关闭开关（big Kill-Switch）”没问题，但激活它意味着你会在 stdout 上看到警告，而这些警告不会出现在 Oracle 的跟踪系统中，但会出现在我们的支持团队那里（至少对于我们的用户和客户是如此）。这是我们很可能投反对票的第二个原因。

我们知道这对于发布日期意味着什么，但是我们认为，更高程度的共识很重要，执行委员的部分职责是保证 Java 生态系统的健康。在当前状态下，对于许多库、框架及应用程序而言，Jigsaw 可能仍然是一个问题。

可是，InfoQ 也了解到，另一个专家组成员 Azul Systems 可能投赞成票。首席执行官 Gil Tene 告诉我们：

关于这一点，我们有点纠结。Jigsaw 是一个对 Java 开发人员有帮助的模块系统，我赞成其中一部分（不是全部）反对意见。在我看来，根据现实世界常见的实际案例，缺少对单个应用程序中同一模块的多版本支持，限制了它在 JDK 之外的可用性（应用程序使用了 Maven Central 程序包 A 和 B，两者均依赖模块 C，但 A 需要 C.1.1.0 ，而 B 需要 C.1.2.1）。

不过，尽管有反对意见，但我们还是会投赞成票。其中许多都是来自沟通不顺畅及过高的期望。虽然有些反对意见是合理的，人们对 Jigsaw 的期望（Java SE 9 的规划）远远超出了它的实际，但我没有理由拒绝它作为一个主要在 JDK 内部使用的模块系统（出于批判 Java SE 9 的立场，我就是这么看待 Jigsaw 的）。在我看来，我们将会看到 Jigsaw 在 JDK 之外的有限应用，对于公开发布的库和可重用代码尤其如此。举例来说，JDK 本身永远不用处理多版本的问题，所以按照现在的情况，Jigsaw 在 JDK 里可以工作得很好。我期望的是，可以为非 JDK 开发人员带来更多好处的“真正的 Jigsaw”（Jigsaw 2.0？）会晚一点推出。Java 10? 或 11?，希望不是永不……但是，in-JDK Jigsaw 已经接近完成，随时可以发布，我没有理由延误 Java SE 9，我不能因为希望重做它或者解决其中部分重大事项而延误整个发布序列。

我们接触过的大多数人都告诉我们，他们尚未达成一致。例如，代表 LJC 的 Martijn Verburg 就告诉我们：

对于 JSR 送审，规范负责人和专家组的分歧如此之大还是很少见。我在执行委员会工作了大约五年，我不记得以前曾经出现过这种情况。

投票即将在 5 月 8 日关闭，JCP 执行委员会正在讨论规范负责人和专家组成员提出的各种观点，并考虑来自更广泛 Java 社区的成员的评论。在投票结束之前的两天时间里，他们会在一起开会，这将是议程上的一个重要课题。伦敦 Java 社区当然认为 EC 颇能代表更广泛的 Java 社区，并且认为它非常适合评估 Jigsaw 以其目前状态对 Java 及其生态系统有益还是有害。

模块化很难，Jigsaw 团队在设计和实现上已经进行了大量的思考，特别是，我们当然不希望看到已经完成的 Java 模块化工作本身被延误。不过，如果更广泛的生态系统拒绝支持当前的设计 / 实现，那么它就无法获得广泛的应用，那至少会让生态系统中的许多人失望。

有趣的是，在我们最初报道这一事件的博文的留言板上，来自 Red Hat 的 David Lloyd 表示，那可能会稍微导致一些延误，直至解决问题：

我觉得，延误几周，讨论、实施、测试让其达到一个最小可接受状态所需要的修改，可能对于每个人而言都是最好（和最现实）的。

我们将看下当投票于 5 月 8 日关闭时会发生什么。

查看英文原文： Mark Reinhold Confirms JPMS (Jigsaw) Will Be Submitted for Public Review, Despite Community Concerns