Alternatives to automatic modules as a concept

[Patrick Reinhart]

Hi Ceki,

You basically already have all within the actual implementation to use service loader with the given interfaces ILoggerFactory and IMarkerFactory. Seems only the actual LoggerFactory/MarkerFactory could be changed and a multi release jar could be set up to use the service loader used as first choice within version 1.7.x and then as only option from 1.8 on…

Cheers Patrick

> Am 20.03.2017 um 13:22 schrieb Ceki Gülcü <ceki at qos.ch>:
> 
> 
> 
> On 3/20/2017 12:07, Alan Bateman wrote:
>> On 20/03/2017 09:29, Ceki Gülcü wrote:
>> 
>>> :
>>> 
>>> Not only do I agree, that's actually the plan for the next SLF4J
>>> version. For what it's worth, to track progress I have also created
>>> 
>>>  https://jira.qos.ch/browse/SLF4J-401
>>> 
>> Good! Is there also an issue tracking releasing it someday as a set of
>> modules?
> 
> There is the parent issue, namely SLF4J-372 and also SLF4J-402 "Jigsaw module declarations".
> 
>> In the mean-time then I would expect existing versions of SLF4J to work
>> on the class path as before. Also existing versions should "just work"
>> as automatic modules on the module path. This goes for the case where
>> both slf4j.api and the logging framework JAR are treated as modules, or
>> where slf4j.api is a module and the logging framework JAR remains on the
>> class path.
> 
> The current plan is to completely abandon StaticXXXBinder mechanism in SLF4J 1.8. SLF4J backends, aka slf4j-compliant logging frameworks, would need to adapt to the ServiceLoader mechanism.
> 
> As for jigsaw module declarations, I expect it to be trivial assuming building under Java 9 but targeting Java 6.
> 
> --
> Ceki