Java 9 default methods in interfaces: from which modules are they invoked?

Question

suppose you have moduleA and moduleB. ModuleA defines an interface (for instance for a Service) and ModuleB has a concrete class that implements the interface (provides the service).

Now if the interface has a default method and you invoke it on the class in moduleB (from another module) is this invocation supposed to be performed inside moduleA or moduleB? Apparently it is from moduleA ... what's the rationale?

Example: suppose you have a code that does this:

InputStream is = this.getClass().getResourceAsStream(fullPath);

if this code lies in the implementation of the service in moduleB the stream will be opened. But if the code lies in the default method in moduleA then when the service is invoked on moduleB you will need to have an "open" resource in moduleB (so it seems that the invocation thinks it is from "outside" moduleB).

would like to read about the reason for that.

thanks

---

editing my question with an example. Suppose you have in moduleA this code:

public interface PropertiesProvider {
    public default Properties get(String domain) {
        Class clazz =this.getClass();
        System.out.println(" CLASS " +clazz);
        InputStream is = clazz.getResourceAsStream(domain) ;
        if (is != null) {
            Properties props = new Properties();
            try {
                props.load(is);
                return props;
            } catch (IOException e) {
                //log
            }
        }
        return null;
    }

}

and in moduleB

public class PropertiesProviderImpl implements PropertiesProvider {}

if you invoke the service from ModuleA the call is traced to come from class PropertiesProviderImpl finds the resource but does not load it if it is not "opened"

if you copy the code into PropertiesProviderImpl the calls is traced to that same class finds the ressource and loads it even when it is not "opened"

So my question is: why the difference since the call comes from the same class? (the difference being that in one case the method is kind-of inherited from the default method in the interface)

Answer 1

Look at the documentation of the getResourceAsStream If this class is in a named Module then this method will attempt to find the resource in the module.

In the first case your code (in moduleA) sees the Type but cannot see the class which implements your Type, because it's in the moduleB. In the second case your code can see the class which "implements" the Type.

Look at the reference bellow, the most important sentences are:

In a modular setting the invocation of Class::forName will continue to work so long as the package containing the provider class is known to the context class loader. The invocation of the provider class’s constructor via the reflective newInstance method, however, will not work: The provider might be loaded from the class path, in which case it will be in the unnamed module, or it might be in some named module, but in either case the framework itself is in the java.xml module. That module only depends upon, and therefore reads, the base module, and so a provider class in any other module will be not be accessible to the framework.

[...]

instead, revise the reflection API simply to assume that any code that reflects upon some type is in a module that can read the module that defines that type.

[Long answer]: reflective-readability

A framework is a facility that uses reflection to load, inspect, and instantiate other classes at run time [...]

Given a class discovered at run time, a framework must be able to access one of its constructors in order to instantiate it. As things stand, however, that will usually not be the case.

The platform’s streaming XML parser, e.g., loads and instantiates the implementation of the XMLInputFactory service named by the system property javax.xml.stream.XMLInputFactory, if defined, in preference to any provider discoverable via the ServiceLoader class. Ignoring exception handling and security checks the code reads, roughly:

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
...

In a modular setting the invocation of Class::forName will continue to work so long as the package containing the provider class is known to the context class loader. The invocation of the provider class’s constructor via the reflective newInstance method, however, will not work: The provider might be loaded from the class path, in which case it will be in the unnamed module, or it might be in some named module, but in either case the framework itself is in the java.xml module. That module only depends upon, and therefore reads, the base module, and so a provider class in any other module will be not be accessible to the framework.

To make the provider class accessible to the framework we need to make the provider’s module readable by the framework’s module. We could mandate that every framework explicitly add the necessary readability edge to the module graph at run time, as in an earlier version of this document, but experience showed that approach to be cumbersome and a barrier to migration.

We therefore, instead, revise the reflection API simply to assume that any code that reflects upon some type is in a module that can read the module that defines that type. This enables the above example, and other code like it, to work without change. This approach does not weaken strong encapsulation: A public type must still be in an exported package in order to be accessed from outside its defining module, whether from compiled code or via reflection.