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].