Still driving off the cliff

[Alan Bateman]

On 22/02/2012 17:39, David M. Lloyd wrote:
> :
>
> And the Java world definitely DOES NOT need a module system that 
> requires special tools and indexes in order to install and run 
> anything!  What is the precedent in other languages? 
I think some tools will be required but they to be as simple as using 
apt-get to install a native package.

> Who would possibly want this kind of API?  End users just want to be 
> able to say "I need these modules".  They don't want to detect service 
> implementations from their capabilities, they just want to say "give 
> me this implementation".  And they definitely don't want their 
> application blindsided by globally installed services!
With ServiceLoader today then the selection of the provider 
implementation is done by whoever is using ServiceLoader API.  In one of 
your mails you mentioned an example from the JDK, namely NIO, where 
there can be multiple file system provider installed. For that example 
the JDK ships with two provider implementations and the API selects the 
providers based on a URI scheme. Other APIs have other ways based on the 
provider's capabilities. There have been calls over the years to provide 
support for selecting providers based on capabilities or some meta data 
but I don't see us going there in Jigsaw. All we're doing is making it 
possible to package service providers as modules and to makes them 
usable with the ServiceLoader API.

> :
>
> Think simplicity, think determinism, think bottom-up design.  We don't 
> need more abstractions and rules, we need fewer!  By having each 
> module import only the modules it uses (including, if desired, 
> implementation modules for services), ServiceLoader continues to work 
> excellently *as it is today* with no modifications whatsoever!  In 
> other words, yes ServiceLoader handles that just fine as it is today!
ServiceLoader is class loader centric and isn't well really suited to a 
world where there isn't a class path and delegation that we have today. 
I think it will have to change to work in the modules world. For now, 
we've changed it so that the ServiceLoader.load and loadInstalled 
methods return a ServiceLoader that iterates over the provider 
implementations that supply (or import to use your term) the user of the 
API. It works as before in legacy (no modules) mode. Once we have more 
complete support for reification then once could envisage containers 
(such as app servers) linking in service providers for specific 
applications running in the container. Whether that involves 
ServiceLoader or not isn't clear at this point.

-Alan.