uses is useless ?

[forax at univ-mlv.fr]

I've resolved my problem of delegation of uses myself,
trying to re-explain my problem, i wanted to provide a method on top of ServiceLoader and force modules that use that API to declare a directive uses.
In fact, you don't need any additional support from the jdk because you can already use the new StackWalker API to get the caller module and do the check using methods of java.lang.reflect.Module.

cheers,
Rémi 

----- Mail original -----
> De: "Alan Bateman" <Alan.Bateman at oracle.com>
> À: forax at univ-mlv.fr
> Cc: "jigsaw-dev" <jigsaw-dev at openjdk.java.net>
> Envoyé: Jeudi 17 Novembre 2016 09:43:41
> Objet: Re: uses is useless ?

> On 16/11/2016 19:41, forax at univ-mlv.fr wrote:
> 
>> :
>> My point is that in teory, that's cool but in reality the module-info of
>> java.base (or java.sql) declares a lot of 'uses' making the whole idea moot.
>> To avoid java.base to use 'uses', we need a way to be able to have a way to
>> delegate the power of the ServiceLoader to another code, so the other code will
>> have to use 'uses'.
> If a consumer is making use of an API in java.base and the
> implementation of that API makes use of services under the covers then
> it is transparent to the consumer of the API. The consumer of the API
> shouldn't need to know anything about the "SPI" types and would be very
> surprising if the user of an API needed to declare `uses` on such types.
> 
> In the JDK then I'm only aware of two cases where the consumer passes a
> service type to an API that doesn't know anything about the service type
> (the two cases are JVMCI and a utility method in javac). Both of these
> cases use addUses to get through the hygiene check.
> 
> jlink is a bit special in that the user of the tool needs at least some
> global knowledge when choosing the service provider modules to include
> in the run time image. As I said, the tool could help more but having it
> do eager service binding is problematic as it tends to maximize rather
> than minimize the number of the modules.
> 
> -Alan.