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

[Robert Scholte]

Hi Peter,

you've been hit by MNG-6371[1]. We've tried to solve this in Maven 3.5.1,  
but we faced other unexpected classloader issues with maven-extensions and  
maven-plugins with extensions. So far we haven't been able to fix it.
This is actually THE reason why Maven 3.5.1 was never released, we  
reverted the classloader related changes and successfully released Maven  
3.5.2.

If you like a challenge or a bit more info: the main issue is when we  
create a new Realm with null[2]. This will create a new ClassLoader with  
parent null[3], meaning no bootstrap classloader.

I can quote Alan:
Rhino used to be the JS engine in older releases and that may have been in  
rt.jar and so loaded by the boot loader. When Nashorn replaced it (in JDK  
8) then it was configured to be defined to the extension class loader so  
this is why the code snippet doesn't find it.

In the Maven mailinglist are several threads trying to define how Maven  
Classloading should work. So far only a few have mentioned this issue.

IIRC some have worked around it by initializing a new classloader.

thanks,
Robert


[1] https://issues.apache.org/jira/browse/MNG-6371
[2]  
https://github.com/apache/maven/blob/4b95ad9fce6dfe7eec2be88f5837e96c7fbd7292/maven-core/src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java#L123
[3]  
https://docs.oracle.com/javase/9/docs/api/java/lang/ClassLoader.html#ClassLoader-java.lang.String-java.lang.ClassLoader-

On Thu, 24 May 2018 12:29:33 +0200, Alan Bateman <Alan.Bateman at oracle.com>  
wrote:

> On 23/05/2018 21:28, Peter Levart wrote:
>> :
>>
>> It's not an official plugin. And it seems that the Maven container is  
>> to blame, not the plugin.
> Robert Scholte is on this mailing list and may be able to comment on  
> this.
>
>
>> 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?
> I wasn't involved in JSR 223 but it may have envisaged scenarios where  
> applications bundle scripting language implementations. This is not too  
> unusual and you'll find several APIs do this to allow for cases where an  
> application is launched in a container environment. Legacy applet and  
> Java EE containers have historically created a class loader per  
> "application" and this becomes the TCCL for the threads in that  
> application.
>
> -Alan