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

　　官方微信：动力节点Java学院

　　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日关闭时会发生什么。