在Java 9中，requires和requires传递语句之间有什么区别？

Question

要求和在模块声明中需要传递的模块语句之间有什么区别？

例如：

module foo {
    requires java.base;
    requires transitive java.compiler;
}

Answer 1

可读性重述

如果模块酒吧requires模块饮料，那么模块系统.

• 加强饮料的存在(称为可靠配置)
• 允许酒吧读取饮料(称为https://blog.codefx.org/java/java-module-system-tutorial/#dependencies-readability)
• 允许条形图中的代码访问饮料中导出的包中的公共类(称为https://blog.codefx.org/java/java-module-system-tutorial/#exports-accessibility)

同样的情况，如果酒吧requires transitive drink -饮料必须存在，可以读取和访问。事实上，对于bar和doesn，transitive关键字不会改变任何事情。

隐含可读性

依赖于的模块 bar 是受transitive影响的模块:任何读取bar的模块也可以读取饮料。换句话说，饮料的可读性是隐含的(这就是为什么这被称为https://blog.codefx.org/java/implied-readability/)。其结果是顾客可以获得饮料的类型。

因此，如果bar requires transitive drink和customer requires bar，那么客户可以阅读饮料，即使它不明确地依赖它。

用例

但是为什么呢？假设您有一个模块，其公共API接受或返回另一个模块的类型。假设bar模块公开返回Drink的实例，这是饮料模块的一个接口：

// in module _bar_
public class Bar {

    // `Drink` comes from the module _drink_,
    // which _bar_ requires
    public Drink buyDrink() { /* ... */ }

}

在本例中，bar使用一个常规的requires作为饮料。现在假设，客户依赖于bar，所以它的所有代码都可以调用Bar::buyDrink。但当它发生时会发生什么呢？

模块系统抱怨客户不读取饮料，因此无法访问Drink。要解决这个问题，顾客还必须依赖饮料。多烦人的事！你不能马上用的酒吧有多没用？

​

​

为此，引入了隐含的可读性:使在自己的公共API中使用另一个模块类型的模块立即可用，而不要求调用方搜索并要求所有涉及的模块。

因此，如果bar requires transitive drink，客户可以开始购买饮料而不必require drink - require bar就够了。它应该做的。

Answer 2

两者之间的主要区别是依赖模块从一个模块到另一个模块的访问。

如果一个模块导出包含签名指向第二个模块中的包的类型的包，那么第一个模块的声明应该包括对第二个模块的requires transitive依赖。此将确保依赖于第一个模块的其他模块能够自动读取第二个模块，从而访问该模块导出的包中的所有类型。

因此，假设您的用例:-

module foo {
    requires java.base;
    requires transitive java.compiler;
}

~>任何依赖于foo模块的模块都将自动读取java.compiler模块

另一方面，要访问模块~>，它们必须再次指定requires子句。

module bar {
    requires foo; // java.compiler is available to read
    requires java.base; // still required
}

Answer 3

requires描述了模块之间如何相互依赖的解析过程。

报价线

A‘要求’指令(不管‘传递’)表示一个模块依赖于其他模块，‘传递’修饰符的效果是导致附加模块也依赖于另一个模块。如果模块M‘需要传递的N'，那么M不仅依赖于N，而且依赖于M的任何模块也依赖于N，这样就可以重构M，从而可以将它的部分或全部内容移动到一个新的模块N中，而不破坏具有“需要M”指令的模块。

简言之：

requires -M模块依赖于其他模块N。

requires transitive -附加模块隐式地依赖于另一个模块。如果M模依赖于N，而其他模P依赖M，那么它也隐含地依赖于N。