ServiceLoader.load(Class, ClassLoader) does not load services exposed in modules and loaded by parent CL

[Peter Levart]

On 05/23/18 19:04, Alan Bateman wrote:
> On 23/05/2018 16:39, Peter Levart wrote:
>>
>> I thought so. This is what debugger told be me about TCCL (debugger 
>> calls .toString() on it by default):
>>
>> ClassRealm[plugin>com.marand.misc:misc-mojo-git:1.24, parent: 
>> jdk.internal.loader.ClassLoaders$AppClassLoader at 1de0aca6]
>>
>> But now that you asked specifically, I also checked the instance and 
>> evaluated .getParent() on it and got null ?! toString is a damn liar!
>>
>> It seems that Maven class loaders don't follow standard delegation 
>> model and so JDK can't climb the chain. Sorry for not checking this 
>> before. There's nothing JDK can do about it, I belive.
> Which Maven plugin is this and is the latest version? The work to get 
> Maven working with JDK 9 got started in 2015 so I'm surprised that 
> there are still issues.

It's not an official plugin. And it seems that the Maven container is to 
blame, not the plugin. The nonstandard ClassLoader is supplied by the 
container. The plugin just uses the most direct and default API possible 
to instantiate JavaScript engine:

jsEngine = new ScriptEngineManager().getEngineByName("JavaScript");

It is the environment the plugin is executing in that doesn't play well 
with how system service providers are located from JDK 9 on - namely, 
the nonstandard ClassLoader that delegates to system class loader, but 
does not express this also in the .getParent() result. I don't know why 
Maven choose this, but closer inspection reveals that its ClassLoader 
does have a "parent", but it keeps it in its own field called 
"parentClassLoader" and doesn't return it from .getParent(). There must 
be a reason for this, but I don't know that it is.

Do other parts of the JDK also use TCCL to bootstrap service lookup by 
default? Isn't it unusual that ScriptEngineManager uses TCCL by default?

Regards, Peter


>
> -Alan