如何在Java 9中避免拆分包 [英] How split packages are avoided in Java 9

问题描述

我是Java 9的新手，我正在参加Java在YouTube上的模块化视频讲座. 他们提到了模块化的3个好处- 1.没有遗失的依存关系 2.没有周期性的依赖 3.没有拆分包.

I am new to Java 9 and was going though the modular video lectures by Java on YouTube. They mentioned 3 benefits of modularization- 1. No missing dependencies 2. No cyclic dependnpcies 3. No split packages.

据我对拆分包的了解，我们可以说一个应用程序依赖于多个依赖关系，比如说abc.pqr.xyz包存在于1个以上的jar中. 这样就有可能从jar1中使用该包中的某些类，而从jar2中使用其他类. 这可能会导致在运行时出现一些难以调试的问题.

As far as I understand about split packages is that let's say an application is dependant on multiple dependncies and let's say package abc.pqr.xyz is present in more that 1 jar. Then there is a chance that some of the classes in that package will be used from jar1 while other classes from jar2. This might lead to some problems at runtime which will be hard to debug.

视频说模块化解决了这个问题. 但这就是我想要了解的东西吗?

Video says modularization solves this issue. But how that's what I am trying to understand?

假设有test.module1，其模块信息如下-

Let's say there is test.module1 which has below module info -

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

另一个模块2，其模块信息如下-

Another module2 with below module info-

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

现在让我们说在我的应用程序中，我添加了这两个模块的依赖关系-

Now let's say in my application I added dependencies of both of these modules-

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

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

Now again I have 2 modular dependencies where there is a chance that some of the classes will be present in both of these modules. So at runtime how it will be resolved from which module to pick up the class definitions? How Java 9 will avoid split packages problem?

推荐答案

使用问题中描述的方案，您将开始面临错误阅读:

With the scenario described in the question, you'll start facing an error reading :

模块test.myapp从test.module1和test.module2

来自 可读性 "noreferrer">模块系统的状态详细说明了模块的使用，并应使您的用例(重点是我的用例)有趣

Readability of the Modules from The State of the Module System elaborates over the use of Modules as follows and shall interest your use-case(emphasis mine):

模块图中定义的可读性关系是基础 可靠配置的证明:模块系统确保

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.

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

the benefit of implying the same in the module system is detailed as well

可靠的配置不仅更加可靠； 也可以是 更快.当模块中的代码引用包中的类型时，则表示 保证可以在该模块或该模块中定义包 恰好是该模块读取的模块之一.

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.

---

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

---

That said, the current solution to your implementation is

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

• if the modules test.module1 and test.module2 are explicit modules, you can choose to implement the package abc.pqr.xyz in either one of them OR you pull it out from both into a separate module test.mergeModule of your own which can thereafter be used as an independent module across its clients.

如果这些(或其中任何一个)是自动模块，则可以使用

if these(or any one of them) are automatic modules, you can make use of the bridge extended to the classpath and let such jar remain on the classpath and be treated as the unnamed module, which shall by default export all of its packages. At the same time, any automatic module while reading every other named module is also made to read the unnamed module.

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

Quoting the document again and to illustrate with an example, so that you can correlate to your question :

如果显式模块com.foo.app中的代码引用了 com.foo.bar，例如，该类型的签名指的是 其中一个JAR文件仍在类路径中，然后在 由于com.foo.app，com.foo.app将无法访问该类型 不能依赖未命名的模块.

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.

这可以通过将com.foo.app暂时视为自动模块来纠正，以便 代码可以从类路径访问类型，直到 类路径上的相关JAR文件可以视为自动 模块或转换为显式模块.

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.

这篇关于如何在Java 9中避免拆分包的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！