Alternatives to automatic modules as a concept
patrick at reini.net
Mon Mar 20 20:44:48 UTC 2017
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…
> 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
>> Good! Is there also an issue tracking releasing it someday as a set of
> 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.
More information about the jigsaw-dev