需求和需要模块声明中的传递模块语句有什么区别？
例如：

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

解决方法:

可读性回顾

如果模块棒需要模块饮料,那么模块系统……

>强制饮酒(称为可靠配置)
>允许酒吧阅读饮料(称为readability)
>允许bar中的代码访问drink中导出包中的公共类(称为accessibility)

如果酒吧需要传递饮料,则完全相同 – 饮料必须存在,可以阅读和访问.事实上,对于酒吧和饮料,传递关键字不会改变任何东西.

隐含的可读性

依赖于条形的模块是受传递影响的模块：任何读取条形图的模块也可以读取饮料.换句话说,暗示了饮料的可读性(这就是为什么这被称为implied readability).结果是客户可以访问饮料类型.

因此,如果酒吧需要传递饮料而客户需要酒吧,那么即使客户没有明确依赖饮料,客户也可以阅读饮料.

用例

但为什么？想象一下,你有一个模块,其公共API接受或返回另一个模块的类型.假设bar模块公开返回Drink的实例,这是来自drink模块的接口：

// in module _bar_
public class Bar {

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

}

在这个例子中,酒吧使用常规的饮料需求.现在说,客户依赖于bar,所以它的所有代码都可以调用Bar :: buyDrink.但是当它发生时会发生什么？

模块系统抱怨客户不读饮料,因此无法访问饮料.为了解决这个问题,顾客也必须依赖饮料.真是个琐事！你不能马上使用的酒吧是多么无用？

出于这个原因,引入了隐含的可读性：使模块在其自己的公共API中使用另一个模块的类型立即可用,而无需调用者追捕并需要所有涉及的模块.

因此,如果酒吧需要传递饮料,顾客可以开始购买饮料而不需要饮料 – 需要酒吧就足够了.正如它应该.