java - Java 9 如何避免拆分包

Question

我是 Java 9 的新手，正在观看 YouTube 上 Java 的模块化视频讲座。 他们提到了模块化的 3 个好处—— 1.没有缺失的依赖 2.无循环依赖 3. 没有拆分包。

据我对拆分包的理解，假设一个应用程序依赖于多个依赖项，并且假设包 abc.pqr.xyz 存在于 1 个以上的 jar 中。 那么有可能该包中的一些类将来自 jar1 而其他类来自 jar2。 这可能会导致运行时出现一些难以调试的问题。

视频说模块化解决了这个问题。 但这就是我想要了解的内容吗？

假设有 test.module1，它具有以下模块信息 -

module test.module1{
exports abc.pqr.xyz;
}

具有以下模块信息的另一个模块 2-

module test.module2{
 exports abc.pqr.xyz;
}

现在假设在我的应用程序中我添加了这两个模块的依赖项-

module test.myapp{
 requires test.module1;
 requires test.module2;
}

现在我又有 2 个模块依赖项，其中一些类可能会出现在这两个模块中。 那么在运行时如何从哪个模块中解析来获取类定义呢？ Java 9 将如何避免拆分包问题？

Answer 1

对于问题中描述的场景，您将开始面临错误阅读:

Module test.myapp reads package from both test.module1 and test.module2

可读性 来自 The State of the Module System 的模块如下详细说明模块的使用，您的用例(重点是我的)应该感兴趣:

The readability relationships defined in a module graph are the basis of reliable configuration: The module system ensures

• that every dependence is fulfilled by precisely one other module
• that the module graph is acyclic
• that every module reads at most one module defining a given package
• and that modules defining identically-named packages do not interfere with each other.

在模块系统中暗示相同的好处也很详细

Reliable configuration is not just more reliable; it can also be faster. When code in a module refers to a type in a package then that package is guaranteed to be defined either in that module or in precisely one of the modules read by that module.

When looking for the definition of a specific type there is, therefore, no need to search for it in multiple modules or, worse, along the entire class path.

---

也就是说，您的实现的当前解决方案是

• 如果模块 test.module1 和 test.module2 是显式模块，您可以选择实现包 abc.pqr.xyz 在其中之一 或者，您将它从两者中拉出到您自己的单独模块 test.mergeModule 中，此后可以在其客户端中用作独立模块。

• 如果这些(或其中任何一个)是自动模块，您可以使用 bridge extended to the classpath并让此类 jar 保留在类路径中并被视为未命名模块，默认情况下应导出其所有包。同时，任何自动模块在读取所有其他命名模块 时也会读取 unnamed module。 。

  再次引用文档并举例说明，以便您可以关联到您的问题:

  If code in the explicit module com.foo.app refers to a public type in com.foo.bar, e.g., and the signature of that type refers to a type in one of the JAR files still on the class path, then the code in com.foo.app will not be able to access that type since com.foo.app cannot depend upon the unnamed module.

  This can be remedied by treating com.foo.app as an automatic module temporarily, so that its code can access types from the class path, until such time as the relevant JAR file on the class path can be treated as an automatic module or converted into an explicit module.