Fwd: Module naming for logging implementations

[Alex Buckley]

On 10/26/2017 1:03 PM, Stephen Colebourne wrote:
> (previously posted on core-libs-dev, moved by request)

(Thanks!)

> Option 1:
> All modules that implement a particular logging API must have the same
> module name
> eg. every module that implements "org.slf4j" (the API) must be named
> "org.slf4j.impl"
>
> Option 2:
> The module name of the implementation can be whatever name makes sense.
>
>
> For most service providers, option 2 is obvious, however for logging
> it is generally the case that only one implementation should be
> present. If all the jar files that implement a specific logging API
> had the same module name (option 1) then the module system could
> ensure that only one was loaded. This is a particular concern as it is
> not uncommon for a jar file in Maven Central to depend on a specific
> implementation of logging when it should only be depending on the API.
>
>
> I'm leaning towards option 2, as it is simpler and does not require
> all implementations to have the same module name (which would be
> difficult to require). Any other considerations I'm missing?

Option 1 opens the door to multiple modules with the same name being 
placed in different directories of the modulepath. Not a good place to 
be, even if no-one is targeting them via 'requires'.

(I think ServiceLoader does not care about duplicate module names when 
scanning modules on the modulepath, and will inspect their 'provides' 
directives regardless. However, I confess that I cannot figure out from 
the ServiceLoader spec which modules are observable during binding.)

Stepping back, there are two big anti-patterns in the world of 
ServiceLoader. First, it is an anti-pattern for a provider module to 
'exports' its provider implementation. Second, it is an anti-pattern for 
a consumer module to 'requires' a particular provider module. Option 2 
fights the second anti-pattern by making provider modules not "stand 
out" more than other modules. This in turn fights the first 
anti-pattern, because a provider module that is not expecting to be 
mentioned in 'requires' will not hurry to 'exports' anything. (Yes, this 
is all a bit soft, but programming with services is primarily about 
mindset.)

Alex