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

closed as off-topic by gnat, mattnz, Dan Pichelman, jwenting, Kilian Foth Jul 14 '14 at 10:14

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions asking us to recommend a tool, library or favorite off-site resource are off-topic for Programmers as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it." – gnat, mattnz, jwenting
If this question can be reworded to fit the rules in the help center, please edit the question.


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.

  • Thanks - It's a JEE web application. I'll edit my question to add that. – JoseK Apr 12 '11 at 7:45
  • @Jose: what do you gonna do, leave it as is or refactor? – Tim Büthe Apr 12 '11 at 9:56
  • Leave as is for this app. – JoseK Apr 12 '11 at 11:03

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

  • 6
    -1: logging needs to be as good as possible! – user1249 Apr 12 '11 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. – Martin Wickman Apr 12 '11 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 '11 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. – Péter Török Apr 12 '11 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. – Ajeet Ganga Nov 30 '13 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.