Slf4j is indeed just a logging facade. However, Log4j is intended to be succeeded by Logback, from the very same authors.
Update: if you'd like to know about another benefit of Slf4j, it's the fact that following (ugly) constructs aren't needed anymore to avoid the toString() unnecessarily been called:
Slf4J is not an alternative for Log4j, but rather provides a Façade for logging, so one can you can plug in your own logging framework. It's mainly useful for libraries. from slf4j.org:
The Simple Logging Facade for Java or (SLF4J) serves as a simple facade or abstraction for various logging frameworks, e.g. java.util.logging, log4j and logback, allowing the end user to plug in the desired logging framework at deployment time.
To answer your question: Slf4j is being adopted by frameworks now, but in your projects, you can keep on using Log4J (or any other)
Looking at the slf4j page it doesn't look like it would replace log4j - it would just allow you to use the same underlying logging framework (e.g. log4j) for your whole application, allowing libraries to hook into that automatically.
First: an important point: Slf4j is the frontend logging (the API), which can use below most of the main loggin systems: log4j or java.util.logging for instance. So it is better to compared sfl4j to commons-logging.
One thing that I hadn't realized is that log4j development is essentially dead. It's currently at version 1.2, and plans for version 1.3 were abandoned in favour of developing log4j 2.0. However, it doesn't appear that 2.0 is in active development. It is worth noting that Ceki Gülcü, the original founder of the log4j project, has moved on to slf4j (see below).
SLF4J has, in my opinion, the huge advantage that you can unify the logging of all the libraries that you use through the bridges that it provides. Neither of the other logging frameworks allows this. This allows projects to smoothly move to SLF4J and ignore the logging framework choices that dependencies have made.
必须选择两个关键 Jar 文件（log4j-over-slf4j.jar 或 slf4j-log4j12.jar）。如果两者都是类路径，则不起作用。如果随机选择一项，则会丢失意外的功能（例如，log4j-over-slf4j.jar 不支持同一类的多个日志文件；例如，一个用于事件日志，一个用于原始数据日志）。
Slf4j is not a real logging facade. Slf4j does not support many features of its implementors. For short, I mention log4j examples below.
Slf4j cannot specify a user selected configuration file, but forces user to use default (log4j.properties or log4j.xml) at one of so many Java roots (each Jar has one root plus JVM root and classes or bin). If two JAR files have it, it is hard to control which one to use safely.
Slf4j cannot support all Log4j levels, such as 'fatal'. When switch big code from Log4j to Slf4j, huge code change effort is needed (e.g. deciding how to rearrange levels).
Two key Jar files (log4j-over-slf4j.jar or slf4j-log4j12.jar) must be chosen. If classpath both, won't work. If choose one randomly, lose unexpected features (e.g. log4j-over-slf4j.jar does not support multiple log files for same classes; e.g. one for events log and one for raw data log).
发布评论
评论（6）
Slf4j 确实只是一个日志门面。然而，Log4j 的目标是由同一作者的 Logback 继承。
更新：如果您想了解 Slf4j 的另一个好处，那就是不再需要以下（丑陋的）构造来避免不必要的
toString()被调用：您可以改为使用参数化消息：
另请参阅 什么是最快的方法（不是）记录？
Slf4j is indeed just a logging facade. However, Log4j is intended to be succeeded by Logback, from the very same authors.
Update: if you'd like to know about another benefit of Slf4j, it's the fact that following (ugly) constructs aren't needed anymore to avoid the
toString()unnecessarily been called:You can instead make use of parameterized messages:
Also see What is the fastest way of (not) logging?
Slf4J 不是 Log4j 的替代品，而是提供了一种用于日志记录的 Façade，因此您可以可以插入您自己的日志框架。它主要对图书馆有用。
来自 slf4j.org：
回答你的问题：Slf4j现在正在被框架采用，但是在你的项目中，你可以继续使用Log4J（或任何其他）
Slf4J is not an alternative for Log4j, but rather provides a Façade for logging, so one can you can plug in your own logging framework. It's mainly useful for libraries.
from slf4j.org:
To answer your question: Slf4j is being adopted by frameworks now, but in your projects, you can keep on using Log4J (or any other)
查看 slf4j 页面，它看起来不会取代 log4j - 它只允许您为整个应用程序使用相同的底层日志框架（例如 log4j），从而允许库自动挂钩。
它看起来更像是 Apache Commons Logging 的替代品，而不是 log4j。
Looking at the slf4j page it doesn't look like it would replace log4j - it would just allow you to use the same underlying logging framework (e.g. log4j) for your whole application, allowing libraries to hook into that automatically.
It looks more like a replacement for Apache Commons Logging than log4j.
第一：重要的一点：Slf4j是前端日志记录（API），它可以使用下面大多数主要的日志系统：例如log4j或java.util.logging。因此，最好将 sfl4j 与 commons-logging 进行比较。
关于Log4j的状态，引用自Java日志记录的状态< /a>（一年前）
First: an important point: Slf4j is the frontend logging (the API), which can use below most of the main loggin systems: log4j or java.util.logging for instance. So it is better to compared sfl4j to commons-logging.
About the state of Log4j, quotes from The state of java logging (one year ago)
在我看来，SLF4J 具有巨大的优势，您可以通过它提供的桥梁统一您使用的所有库的日志记录。其他日志框架都不允许这样做。这使得项目可以顺利迁移到 SLF4J，并忽略依赖项所做的日志框架选择。
SLF4J has, in my opinion, the huge advantage that you can unify the logging of all the libraries that you use through the bridges that it provides. Neither of the other logging frameworks allows this. This allows projects to smoothly move to SLF4J and ignore the logging framework choices that dependencies have made.
Slf4j 不是真正的日志外观。
Slf4j 不支持其实现者的许多功能。
简而言之，我在下面提到了 log4j 示例。
Slf4j is not a real logging facade.
Slf4j does not support many features of its implementors.
For short, I mention log4j examples below.