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
