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ü <c...@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
