We are reviewing our JEE web application for some planned refactoring and one of the suggestions is to replace log4j with logback or slf4j

The team is not clear on whether we should do this - because currently we want to follow if it ain't broke, don't fix in this area.

Edit: I'm not asking for a comparison of the logging frameworks, but whether it is a valuable refactoring element to change the framework when we're quite happy with log4j

4 Answers 4


One important question you should take into account: Do you build a library that is used by someone else or do you build the end product?

In the first case, SLF4j is very important, because someone will integrate your library in his software that already has logging in place and it would be nice if your classes just use that.

In the second case, I would say you can just leave it as it is. Maybe think about using slf4j on the next project.


Don't. Better spend your time implementing useful, valuable features instead.

  • 6
    -1: logging needs to be as good as possible!
    – user1249
    Apr 12, 2011 at 7:07
  • 7
    So log4j, which they use, isn't useful enough? Replacing frameworks just because it's posibble, is a waste of time. The OP even stated logging wasn't broken. Apr 12, 2011 at 7:08
  • 1
    I wouldn't vote this down. Martin could be right. If Jose has some finished product (not a library, see my answer) he should just leave it as is and spend time somewhere else...
    – Tim Büthe
    Apr 12, 2011 at 7:32
  • 2
    @Thorbjørn, no, logging (as features in general) needs to be as good as needed. If they have no problems with Log4J, (btw you haven't cited any either which would make it necessary to replace it), there are most probably better uses of their time. Apr 12, 2011 at 7:46
  • 1
    -1 : Unconditional preference of one over another is IMHO iswrong. Just try contrasting this answer with conditionality of Tim Bueth's answer. Nov 30, 2013 at 16:37

If Log4J works for you, there's no reason to change that. If it doesn't, look for an alternative that does do what you need, which may or may not be slf4j.

Just because someone says something is nicer than something else should never be a reason to change your entire application (or to adopt that something new at all).


Slf4j is an API that allows you to choose whether to use log4j, logback or the default jdk logging at deployment time instead of deciding at compilation time (which is what happens when you code directly to log4j)

Slf4j also provide the {}-construct which can delay expensive toString() calls, avoiding them entirely if the log statement is not enabled.

You can then choose the engine later.

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