Still driving off the cliff

[David M. Lloyd]

On 02/22/2012 02:16 PM, Alan Bateman wrote:
> 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.

Just to clarify I was talking about the selector provider API, not the 
filesystem API (I'm old school like that).

>> 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.

But the modular world *is* class loader centric, that's my whole point. 
  Java is already 80% of the way towards being modular as of Java 7. 
All it is missing is a multiple-delegate base class loader and a module 
loader concept which creates class loaders for modules.  A 1:1 
module:class loader mapping is completely natural on many levels, and I 
have yet to see a compelling argument to the contrary.  And in this 
model ServiceLoader works like a champ.

> 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.

My point is that by recognizing that a class loader *already* is a 
module by another name, you should realize that no new API is needed and 
no dual-mode situation should even arise.

> 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.

We already have that today.  Granted TCCL is considered ugly by some, 
but all it's really missing is a clear definition of what it *means*. 
That's what most users (and classically, framework developers) don't 
get.  It *means* your current application module.  That's the only 
meaning that makes any sense.  And there's no way that TCCL is going to 
go away just because you deprecated it and created "new" mode versus 
"old" mode.  It just needs to be formalized.  On app startup, set TCCL 
to the main application module's class loader.  In JavaEE, set it to the 
currently executing deployment.  Consistent and simple.  And it fits the 
existing java.util.ServiceLoader like a glove.

-- 
- DML