问接口中的Java 9默认方法:从哪些模块调用它们？

EN

查看getResourceAsStream If this class is in a named Module then this method will attempt to find the resource in the module.的文档

在第一种情况下，您的代码(在moduleA中)可以看到Type，但是不能看到实现Type的类，因为它在moduleB中。在第二种情况下，您的代码可以看到“实现”Type的类。

看下面的参考资料，最重要的句子是：

在模块化设置中，只要包含提供者类的包为上下文类加载器所知，类：：forName的调用就会继续工作。但是，通过调用提供者类的构造函数--反射newInstance方法--将无法工作：提供程序可能是从类路径加载的，在这种情况下，它将位于未命名模块中，或者在某个命名模块中，但在这两种情况下，框架本身都在java.xml模块中。该模块只依赖并因此读取基本模块和，因此框架无法访问任何其他模块中的提供程序类。

..。

相反，修改反射API，只需假设反映某种类型的任何代码都在一个模块中，该模块可以读取定义该类型的模块.。

长答案：反光可读性

框架是一种在运行时使用反射加载、检查和实例化其他类的工具. 给定在运行时发现的类，框架必须能够访问它的一个构造函数才能实例化它。然而，就目前情况而言，情况通常并非如此。 该平台的流XML解析器，例如，加载和实例化系统属性javax.xml.stream.XMLInputFactory命名的javax.xml.stream.XMLInputFactory服务的实现(如果定义的话)，而不是通过ServiceLoader类发现的任何提供者。忽略代码读取的异常处理和安全检查，大致如下：

String providerName
    = System.getProperty("javax.xml.stream.XMLInputFactory");
if (providerName != null) {
    Class providerClass = Class.forName(providerName, false,
                                        Thread.getContextClassLoader());
    Object ob = providerClass.newInstance();
    return (XMLInputFactory)ob;
}
// Otherwise use ServiceLoader
...

在模块化设置中，只要上下文类加载器知道包含提供者类的包，Class::forName的调用就会继续工作。但是，通过反射newInstance方法调用提供程序类的构造函数是行不通的:提供程序可能是从类路径加载的，在这种情况下，它将位于未命名模块中，或者可能在某个命名模块中，但在这两种情况下，框架本身都在java.xml模块中。该模块只依赖于并因此读取基本模块，因此框架将无法访问任何其他模块中的提供程序类。 为了使框架能够访问提供者类，我们需要使提供程序的模块被框架的模块读取。我们可以要求每个框架在运行时明确地为模块图添加必要的可读性边缘，就像本文档的早期版本一样，但是经验表明，这种方法很麻烦，也是迁移的障碍。 因此，我们只是修改反射API，假设反映某种类型的任何代码都位于可以读取定义该类型的模块的模块中。这使得上面的示例和其他类似的代码能够在不改变的情况下工作。这种方法并不会削弱强大的封装:公共类型必须仍然在导出的包中，这样才能从其定义模块之外访问，无论是从编译的代码还是通过反射。

由于我们不完全理解之前的反应，所以我们进行了一些额外的测试

在每个测试中，资源文件都不会被“打开”。

1)调用clazz.getResouceAsStream的代码是定义服务的默认接口方法。实现接口的类不定义任何方法。

-> this.getClass()生成实现类，测试无法找到资源

2)我们在默认方法中添加了此代码

对象obj = clazz.getConstructor().newInstance()；

是的，它失败了

3)我们更改了代码，因此PropertiesProvider是抽象类，PropertiesProviderImpl是从它继承的。

同样的行为。

因此，是的，这意味着如果继承或直接调用相同的代码，其行为将有所不同。这是令人担忧的:这意味着语言的内部逻辑将导致复杂的拜占庭行为(我们抛弃C++的原因)。