ServiceLoader in the JDK

[Alan Bateman]

On 24/05/2012 12:41, Paul Sandoz wrote:
>
> So it is clear that all the hacks should go away and in module mode the only call that really makes sense is load(Class, ClassLoader) with the appropriate ClassLoader of the module.
The other thing is that we'll need to update ServiceLoader's javadoc to 
specify how the methods work with modules. The loadInstalled method for 
example is specified to be the equivalent of load(S,<ext-CL>) but there 
isn't an extension class loader when running with modes. The load(Class) 
method is also prickly because the TCCL may be set to null or 
getSystemClassLoader.

>
> So this:
>
>    ServiceLoader.load(HttpServerProvider.class, ClassLoader.getSystemClassLoader());
>
> Could change to:
>
>    ServiceLoader.load(HttpServerProvider.class, Platform.isModuleMode()
>          ? HttpServerProvider.class.getClassLoader()
>          : ClassLoader.getSystemClassLoader());
This looks right to me. When running with a classpath then it searches 
the classpath for providers as before. When running with modules then 
the httpserver's module declare will "require service 
HttpServerProvider" and so will be linked to the http server providers 
that are installed.

>
>
> The choice of null or non null for say Object.class.getClassLoader() is clearly going to affect things here for services in the base module.
Yes, that is a good point to include in null vs. module class loader 
debate and that will decide whether a helper method is required too.


> :
>
>
> Perhaps we need to introduce an annotation on methods ServiceLoader.load(Class ) and ServiceLoader.loadInstalled(Class ). When compiling in modular mode optional lint like warnings could be given. If such annotations are retained at runtime it should be possible to detect on execution.
>
I'm not following you on the need for annotations but load(Class) is 
clearly a discussion point as the TCCL might be set to something that 
doesn't make sense when running with modules.

-Alan