If I am developing a Java library, is it good practice to issue log statements from within the library's code?

Having logging within the library will make debugging and troubleshooting more transparent. However, on the other hand, I do not like littering my library code with logging statements. Are there any performance implications to consider as well?


2 Answers 2


Yes you should. Using a logging facade like SLF4J gives you flexibility without burdening your users with a particular logging framework.

Authors of widely-distributed components and libraries may code against the SLF4J interface in order to avoid imposing an logging framework on the end-user of the component or library. Thus, the end-user may choose the desired logging framework at deployment time by inserting the corresponding slf4j binding on the classpath, which may be changed later by replacing an existing binding with another on the class path and restarting the application. This approach has proven to be simple and very robust.

Also, if your users don't include an SLF4J jar (from the user's guide):

As of SLF4J version 1.6.0, if no binding is found on the class path, then slf4j-api will default to a no-operation implementation discarding all log requests.

If you're concerned about performance implications of logging, check out this SLF4J FAQ entry. The idea is that you provide parameters to log statements instead of adding them into a String inline:

The following two lines will yield the exact same output. However, the second form will outperform the first form by a factor of at least 30, in case of a disabled logging statement.

logger.debug("The new entry is "+entry+".");
logger.debug("The new entry is {}.", entry);

Is SLF4J yet another logging facade?

SLF4J is conceptually very similar to JCL. As such, it can be thought of as yet another logging facade. However, SLF4J is much simpler in design and arguably more robust. In a nutshell, SLF4J avoid the class loader issues that plague [Jakarta Commons Logging].

  • Is there a good open source library that logs within the library code that you can point to? so we can see how it is done? Commented Dec 16, 2017 at 23:18
  • The Spring framework is a fairly well-known Java library that does this; in their case they chose JCL. Commented Dec 20, 2017 at 20:16

Yes, you should log from your library code. It not only helps you develop, but the people who use the library will find it useful. Remember that you can always set the logging levels to only show the log statements you need - and they can do the same.

Recently I was using Mybatis, an open source ORM tool. I was debugging an issue where a query I thought should have been correct was returning no results. It was a parameterized query, and since Mybatis has logging within its library code, I was able to turn it on and see the actual query being run. It was easy to tell that I swapped two parameters. Without logging in the library I couldn't have found the problem nearly as quickly.

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.