ServiceLoader in the JDK
Alan.Bateman at oracle.com
Thu May 24 05:13:41 PDT 2012
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
> 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.
More information about the jigsaw-dev