Module naming for logging implementations

[Cédric Champeau]

There's a good argument for 1, though. log4j typically doesn't separate api
and implementation. So a module would "require 'log4j'". It means that if
another module like slf4j doesn't "pretend to be" log4j, it's now going to
fail. Said differently, Jigsaw kills module replacements and fatjars.

2017-10-27 0:26 GMT+02:00 Stephen Colebourne <scolebourne at joda.org>:

> Thanks Alex and David, those are good arguments. So option 2 it is.
> Stephen
>
> On 26 October 2017 at 23:05, David Lloyd <david.lloyd at redhat.com> wrote:
> > On Thu, Oct 26, 2017 at 3:03 PM, Stephen Colebourne
> > <scolebourne at joda.org> wrote:
> >> 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.
> >
> > This is actually a general special case (if you follow my meaning):
> > that of an API which uses services to locate an implementation, yet
> > typically only one implementation should be existent and used.  For
> > example, I/O or other platform-dependent systems also spring to mind:
> > they have a common API, but you generally only want one implementation
> > (except maybe in some special cases - just like for logging).
> >
> > I think that in any case, be it a singleton-ish provider case like one
> > of the above or a multiple-provider case, it is always appropriate to
> > choose a unique module name for implementations. It's not appropriate
> > for an API to prescribe an implementation module name.
> >
> > Perhaps we can enhance Jigsaw in the future with some kind of feature
> > that enforces singleton implementations, if it becomes any sort of
> > practical problem.
> >
> > --
> > - DML
>