Eliminate silent dependencies was: Mandatory service requirement

[Alan Bateman]

On 22/02/2012 00:31, Jesse Glick wrote:
> Alan Bateman wrote:
>> "requires service S" means >= 1 implementations of S required.
>
> But there is a difference between saying "you must somehow provide an 
> implementation of S if this module is to be used or the system will 
> report an error", which can arguably be useful (in my experience 
> rarely); and actually going out and silently picking one from the 
> repository when none was provided, which is not obviously implied by 
> the above declaration and might be bad.
>
>> "requires optional service S" means >= 0 implementations of S required.
>
> Which means nothing at all :-) as I noted at the end of my original 
> post "Mandatory service requirement" - there is no reason why you 
> should have to declare that you might load a service, if you can 
> gracefully handle zero implementations.
Jigsaw is a static module system so it needs to know that 
implementations of S that may be required at runtime so as to include 
them in the configuration. Furthermore it pre-builds the maps so that 
there is no searching at runtime. Having an application module (the user 
of the API, not the one calling ServiceLoader.load) declare a dependency 
on a module with a specific provider implementation isn't the same 
thing. It could be made to work for some case but I'm not sure that it 
would scale. So for now, and in the graph terms, we need an edge (of a 
different color) from the module using ServiceLoader.load(S.class) to 
the module that provides S.

>
> :
>
> For large apps with a user-level plugin system, I would expect Jigsaw 
> to offer reflective APIs so you could build a UI to load named modules 
> and make their services available.
Yes, this should come in time as it is critical to container support. 
Exactly how this works with services remains to be seen.

> :
> Agreed that there are a lot of different variants. However we should 
> not advocate using old-style ClassLoader hacks (especially 
> Thread.contextClassLoader), which can break in all sorts of tricky 
> ways and do not compose well - part of the justification for an 
> official module system in Java is to simplify this kind of thing in 
> the future. I think plain ServiceLoader.load(Class), understood to 
> search in all modules in the loaded configuration, can work for all of 
> the cases where available services must be discovered; if you need to 
> discriminate among implementations, call some method on each (e.g. 
> String[] supportedDigestImplementations()).
>
Right, Thread.contextClassLoader was a bad idea and just not interesting 
in a modules world. ServiceLoader is also class loader centric and not a 
good fit either. In the current prototype then ServiceLoader.load(Class) 
does not use the Thread.contextClassLoader when in module mode.

-Alan