Alternatives to automatic modules as a concept

[Alan Bateman]

On 19/03/2017 21:48, Gunnar Morling wrote:

> Is there a way to execute some code when a module is "activated" or
> resolved? I'm not sure what the current word is in Jigsaw terms, but I
> hope it becomes clearer in the following.
>
> To overcome the issue of dependency cycles between slf4j API and
> implementations (when treating them as named modules by adding module
> descriptors, as required for using slf4j in a modular runtime image),
> I've been experimenting with injecting a class into the slf4j.api
> module which establishes the read from API to impl dynamically:
>
>      public void addImplReads() {
>          Module apiModule = org.slf4j.Logger.getClass().getModule();
>          apiModule.addReads( apiModule.getLayer().findModule(
> "slf4j.simple").get() );
>      }
>
> This technique requires "someone" to call this method, before invoking
> any method on the slf4j API. That could be done by the user's
> application, but it'd be much more user-friendly if this could happen
> automatically if the slf4j API module is resolved. Hence I'm trying to
> figure whether one can register a callback or similar and be notified
> in that case.
>
There isn't any notification/callback. Also it's not clear to me that 
injecting code into SLF4J is the right thing to do (it feels like hacking).

If I were a SLF4J maintainer then I think I would re-visit how the API 
locates the logging framework binding. Specifically I would look to 
migrate it to services. So rather than each binding a 
org.slf4j.impl.StaticXXXX classes, it would instead provide an 
implementation of a service type that SLF4J puts in an exported package. 
It may be that cleaning up this area can be done without any impact to 
user code and I would expect the issue of the simple binding to just 
fall out of the wash.

-Alan.