转载

JPMS模块对于库包开发人员的负面效应

Java 9引入了一个主要的新功能：JPMS，即Java平台模块系统，但是对于专门提供库包开发的程序员却有负面效果。

Java 8可能是有史以来最成功的Java版本，它被广泛使用，因此，几乎所有开源库都在Java 8上运行。

Java 9于2017年9月发布，但它不是一个会连续支持多年的版本，相反，它只有六个月的生命周期，现在已经过时了，因为Java 10都已经被淘汰了，在以后六个月的时间里，Java 11将会淘汰Java 10等等。

但幸运的是，Java 11将是一个“长期支持”（LTS）版本，具有几年的安全性和错误支持（Java 8也是LTS版本），因此，即使Java 10已经淘汰，Java 8仍然是开源库开发人员目前正确定位的合理Java版本，因为它是当前的LTS版本。

但是当Java 11出现时会发生什么？由于Java 8在Java 11发布后不久将不再受支持，因此合理的升级路径应该是11，不幸的是，迅速转移到Java 11可能存在风险。

模块路径

首先了解一下类路径和模块路径之间的区别，类路径仍然存在于Java 9+中，以和Java8相同的方式工作。

模块路径则是新的，当jar文件位于模块路径上时，任何module-info都会用于更严格的JPMS规则，例如，一个public方法不再可调用，除非它被明确配置为exported。

升级以后，需要将旧的非模块化jar文件放在类路径class-path上，同时将新的模块化jar文件放在模块路径module-path上，然而，没有人可以强制你执行，这就带来会造成混乱的情况，有四种可能性：

1. 在模块路径上的放置你的模块化后的jar包

2. 在类路径上的放置你的模块化jar包

3. 在模块路径上的放置非模块化jar包

4. 在类路径上的放置非模块化jar包

为确保你的库包正常工作，需要在类路径和模块路径上进行测试。例如，与类路径相比，模块路径上的服务加载非常不同。一些资源查找方法也完全不同。

进一步复杂化的是，JPMS没有明确支持测试，为了测试模块路径上的模块（这是一个紧密锁定的软件包集），必须使用--patch-module 命令行标志，此标志有效地扩展了模块，将测试包添加到与测试类相同的模块中，（如果你只测试公共API，你可以在不使用补丁模块的情况下执行此操作，但是在Maven中你需要一个全新的项目和pom.xml来实现这种方法，可能很少见。）

在最新的Maven surefire插件（v2.21.0及更高版本）中，使用了patch-module标志，但如果你的模块具有可选的依赖项，或者您有其他测试依赖项，则可能必须手动添加它们。

鉴于这种情况，开源库包开发人员应该做些什么？

选项1，什么都不做

在大多数情况下，在Java 8或更早版本上编译的代码在Java 9+的类路径上运行得很好，所以，你可以什么都不做，忽略了JPMS。

问题是如果有其他项目将取决于你的库，如果不采用JPMS，你会间接阻止这些项目的模块化。（一旦项目的所有依赖关系都被模块化，整个项目才能完全模块化。）

当然，如果你的代码不能在Java 9+上运行，比如已经使用了sun.misc.Unsafe，那么还需要解决其他问题。

并且不要忘记用户如果将jar文件放在class-path或module-path上。你可能需要有两个测试。

选项2，添加模块名称

Java 9+能识别MANIFEST.MF文件中的新条目，Automatic-Module-Name条目允许jar文件声明其名称，可如果它想转为的模块化jar文件时可以使用，以下是如何使用Maven添加它：

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-jar-plugin</artifactId>
  <configuration>
   <archive>
    <manifestEntries>
     <Automatic-Module-Name>org.foo.bar</Automatic-Module-Name>
    </manifestEntries>
   </archive>
  </configuration>
 </plugin>

这是一个很好的简单方法，它保留模块名称，并允许依赖于jar文件的其他项目完全模块化，如果他们愿意。

但由于它如此简单，很容易忘记测试方面，同样，jar文件可能还会放在类路径或模块路径上，两者的行为可能完全不同，事实上，现在它有一些模块信息，工具可能会以不同的方式对待它。

当Maven看到Automatic-Module-Name它时，它通常将其放在模块路径而不是类路径上，这样可能反而没有任何效果，达不到我们使用这个选项的目的；或者它可能会显示你的代码在类路径上可工作，但在模块路径上不工作的错误。

现在使用Maven，必须使用surefire插件v2.20.1来测试类路径（一个不知道模块路径的旧版本），要在模块路径上进行测试，请使用v2.21.0，在这两个版本之间进行切换当然需要一个手动过程。

选项3，添加module-info.java

这是关于JPMS的众多网页和教程中描述的完全模块化方法。

 module org.foo.bar {
   requires org.threeten.extra;
   exports org.foo.bar;
   exports org.foo.bar.util;
 }

那么，这对开源项目有什么影响呢？

与选项2不同，你的代码现在为Java 9+准备好了，Java 8编译器却无法理解该文件。我们真正想要的是一个包含Java 8类文件的jar文件，但module-info.java只包含在Java 9+下编译的文件，理论上，在Java 8上运行时，module-info.class文件将被忽略。

Maven有一种技术可以实现这一目标。虽然这项技术运作良好，但事实证明这远远不足以实现目标，要实际获取适用于Java 8和9+的单个jar文件，需要：

1. 使用Java 9+上的发布一个微构建Java 8的标识

2. 添加一个OSGi，实现功能过滤器，让它仍然与Java 8兼容

3. 在Java 8上构建时，从maven-javadoc-plugin中排除module-info.java

4. 使用maven-javadoc-plugin v3.0.0-M1，手动将依赖项复制到目录，并使用其他Javadoc命令行参数引用它们。

5. 从maven-checkstyle-plugin中排除module-info.java

6. 从maven-pmd-plugin中排除module-info.java

7. 手动交换maven-surefire-plugin的版本来测试模块路径和类路径

集成 Java 9 之后，代码可能会从650行增加到862行，增加了很多复杂性，包括配置文件和变通方法。

升级Java9+以后，你的项目可能再也不能被Android使用了（因为这个团队似乎在添加一个简单的“忽略模块信息”规则方面动作很慢）；许多使用旧版字节码库（如ASM）的工具也会失败 - 我有一个报告称特定版本的Tomcat / TomEE无法加载模块化jar文件，我最终不得不发布一个“旧的”的非模块化jar文件来应对这些情况，这是非常令人沮丧的。

虽然我已经添加module-info.java到了一些项目，但我不能推荐其他人这样做 - 这是一个非常痛苦和耗时的过程。考虑它的时间似乎是等Java 11或更高版本被广泛采用时。

总结

截至今天，JPMS对库包发布者来说是一种痛苦，模块路径与类路径的分离是问题的核心。如果没有在模块路径和类路径上进行测试，你真的无法发布一个库包 - 有一些细微的角落情况，环境不同。

原文 https://www.jdon.com/49968

正文到此结束