Question

I thought SLF4J would load org.slf4j.impl.StaticLoggerBinder via reflection but looking at the code in org.slf4j.LoggerFactory, it is not the case:

StaticLoggerBinder.getSingleton().getLoggerFactory();

That might suggest that when they packaged the slf4j-api.jar, they had either slf4j-simple.jar (or slf4j-nop.jar) in the classpath, however that would result in a circular dependency as ILoggerFactory interface that the above method returns is defined in slf4j-api.jar.

So, I think when they packaged slf4j-api.jar, they had a stub implementation of StaicLoggerBinder (and other similar classes) which they would compile but then remove the .class files from the jar. Sounds a bit unkosher, doesn’t it?

What kind of build tool would one use to achieve such a result? Specifically, if I am using Maven, how do I build such jars where classes produced during compile time are excluded from the artifact? There could be anonymous and other inner/nested classes being produced too, should they be removed too?

Answer 1

Take a look at pom.xml and at the sources of slf4j-api.

  <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-antrun-plugin</artifactId>
    <executions>
      <execution>
        <phase>process-classes</phase>
        <goals>
         <goal>run</goal>
        </goals>
      </execution>
    </executions>
    <configuration>
      <tasks>
        <echo>Removing slf4j-api's dummy StaticLoggerBinder and StaticMarkerBinder</echo>
        <delete dir="target/classes/org/slf4j/impl"/>
      </tasks>
    </configuration>
  </plugin>

So, I think when they packaged slf4j-api.jar, they had a stub implementation of StaicLoggerBinder (and other similar classes) which they would compile but then remove the .class files from the jar.

That’s right and it’s necessary to implement static binding.