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)

From what I remember classpaths are trees, the getResourceAsStream start from the classpath related at the classloader of the class of this (in your case, who loaded that class), search in it, if it doesn't find the resource it fallback on the parent classloader and its classpath — rascio
– rascio, Commented Mar 6, 2018 at 15:44
"The Class.getResourceXXX methods are caller sensitive" certainly but how come the "invoker" of getResource is not in ModuleB since it's where the implementing class lies? the implementation of the service inherits (sort of) from the default method ... so why is it that if the code is explicitly in moduleB it works but if inherited in moduleB then the behavior is different? — bear
– bear, Commented Mar 6, 2018 at 17:17
I have edited my initial question trying to explain what worries me. Thanks for any explanation I can understand. — bear
– bear, Commented Mar 7, 2018 at 13:12

Andrew Sasha · Accepted Answer · 2018-03-09 09:09:30Z

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.

"n 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." do you mean that if the package of PropertiesProviderImpl had been "exported" then the code will have behaved as if from the class? Apparently this is not the case.
Sorry, for waiting, busy days :( I should learn more about it too :(. Back to your main question look at this: openjdk.java.net/jeps/261#Risks-and-Assumptions especially to 1st and 4th points
well it seems that I need to read the fine print "module is readable by the module containing the code that is attempting to access it" it means that only the code of the super-class that "contains" it applies the rules (not the inherited code in the subclass!). So for the sake of modularity it violates the rules of inheritance ... I suppose that it is a catch 22 situation and specifications opted for the lesser of two evils.

bear · Accepted Answer · 2018-03-12 10:01:23Z

since we didn't understand precisely the previous response we carried some additional tests

in each test the resource file is not "opened"

1) the code invoking clazz.getResouceAsStream is in default method of interface defining the service. The class implementing the interface does not defines any method.

-> this.getClass() yields the implementing class , tests fails to find resource

2) we added this code in the default method

Object obj = clazz.getConstructor().newInstance();

and yes it fails

3) we changed the code so PropertiesProvider is abstract class and PropertiesProviderImpl inherits from it

same behaviour.

So yes it means that the same code will behave differently if you inherit from it or just invoke it directly. This is worrying: it means the inner logic of the language is going to lead to convoluted byzantine behaviours (the reason why we dumped C++).

Collectives™ on Stack Overflow

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

2 Answers 2

3 Comments

Comments

Hot Network Questions

Collectives™ on Stack Overflow

2 Answers 2

3 Comments

Comments

Related