The SLF4J documentation says that it's best practice for libraries to not include a concrete logging binding.

I'm wondering what to do about transitive dependencies though. Let's say my library A depends on another library B which depends on commons-logging. Should the pom.xml for A have an <exclude> for commons-logging or not?

If it does it would also have to include a dependency on jcl-over-slf4j because users of my library would not know that some component might use commons-logging for logging without looking at the pom.xml. Granted, this way they also have to look at the pom.xml and see slf4j in there.

The other option is to just use slf4j-api in my library A and let the end-user application Z deal with all exclusions and include all necessary bridges once.

What would be considered best practice (if there is one)?

  • 1
    I'm not too familiar with dependency management in Java, so I won't write an answer. I think the general pattern is to declare logging dependencies that only rely on abstract classes or interfaces in your libraries. The application, which imports your libraries, declares the concrete implementations of those logging abstractions consumed by the libraries. Basically, your libraries should only use abstract classes or interfaces for logging purposes, but the application depends on a concrete implementation of those abstractions, which are passed on to the libraries. May 24, 2023 at 20:42

1 Answer 1


The SLF4J documentation says that it's best practice for libraries to not include a concrete logging binding.

Thats your answer!

Include the dependency on the logging API that you personally use. Maven will transitively bring in any logging API's from any 3rd party libraries you depend upon.

The user of your library will have two logging API's to deal with. Hence the downstream developer can choose what logging implementation they want to use and include the appropriate bridges.

To put it another way: you don't know what the final logging implementation will be so you can't bridge to it correctly.

  • Thank you. I see what you mean. I do believe that there's an argument to be made for SLF4J Bridges to not be a concrete "binding" though. May 25, 2023 at 18:21
  • I don't have a strong position on whether or not we should apply the term concrete to bridges. In practice libraries that include bridges and concrete implementations cause the same problem - I have to exclude them if the library author makes different choices to me. I do not see any any special case arguments to treat bridges differently to concrete implementations in this regard.
    – DavidT
    May 25, 2023 at 20:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.