----- Mail original ----- > De: "Alan Bateman" <[email protected]> > À: [email protected] > Cc: "jigsaw-dev" <[email protected]> > Envoyé: Mercredi 16 Novembre 2016 11:44:21 > Objet: Re: uses is useless ?
> On 16/11/2016 10:25, [email protected] wrote: > >> : >> The whole point of uses is to enable a kind of static analysis on the service >> dependencies, >> if 'uses' is not required, if you can easily bypass it or it doesn't provide >> useful information, >> then it should be removed from the spec. > `uses` is used to link the consumers of services to the providers of > services. If nobody `uses S` then the modules that `provides S with ...` > will not be resolved (assuming nobody directly depends on these service > provider modules). 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'. > > The scenario where a framework uses ServiceLoader on behalf of a > consumer really needs the consumer to declare that it uses the service > type, otherwise there is no guarantee that the modules that provide > implementation of the service will be resolved. yes ! if a class calls DriverManager.drivers(), 'uses' should be defined on the module of the class and not on the module of DriverManager, as this is currently the case. Rémi > >> : >> Yes, jlink doesn't do that, but my tool on top of jlink does it :) >> But as i said above, if the information given by 'uses' do not allow to do >> static analysis like finding the root modules (services included), it perhaps >> means that 'uses' doesn't worth its own weight. > jlink could do service binding > (s/resolveRequires/resolveRequiresAndUses) but all the initial feedback > was that people wanted the minimum number of modules in the image. It's > not hard to have jlink make some suggestions, it just hasn't been > implemented (this is what the open issue in JEP 282 is about). > > -Alan
