忘了何時聽老師說過,牛逼的公司只管定義接口,屌絲廠商實現接口,相似 JDBC 的實現即是如此,用在 slf4j, 總以爲有些相似,原本 SUN 有機會在需求產生以前設計一套漂亮的日誌框架來一統天下,惋惜恰恰要拖到 JDK1.4, 而這套原生的日誌框架也沒有足夠漂亮,而以前早已經通過市場考驗的日誌框架也在不斷持續的改進,log4j,logback, common-logging 等等已經在許多系統中長久駐足。html
翻到Java中的日誌框架史,看到下面有趣的文字java
最先出現的日誌框架是apache提供的log4j,使用最爲普遍,成爲了Java日誌的事實上的標準;然而當時Sun公司在jdk1.4中增長了JUL(java.util.logging),企圖對抗log4j,因而形成了混亂,固然此時也有其它的一些日誌框架的出現,如simplelog等,簡直是亂上加亂。
解決這種混亂的方案出現了:抽象出一個接口層:因而開源社區提供了commons-logging,被稱爲JCL。抽象時參考了log4j、JUL、simplelog,對它們進行了適配或轉接,這樣就一統江湖了。
看上去如今已經很是完美了,但好景不長,log4j的做者(Ceki Gülcü)以爲JCL不夠優秀,他要搞出一套更優雅的出來,因而slf4j就出現了,而且親自實現了一個親子——logback(有點,老子又回來了的感受^_^)。好吧,確實更優雅了,但混亂局面又出現了,以前使用JCL的怎麼辦呢,因而Ceki Gülcü在slf4j又對JCL做了橋接轉換,然而事情還沒完,Ceki Gülcü又回來拯救本身的「大阿哥」——log4j,因而log4j2就誕生了,同時log4j2也加進了slf4j體系中。
PS:SLF4J是在Compile綁定實現的,而JCL是Runtime時綁定的。apache
SLF4J ( The simple logging facade for java ) 做爲諸多日誌框架的門面或者抽象,這些框架包括java.util.logging, logback 和 log4j. slf4j 容許終端用戶在部署系統時想使用插件同樣來選擇使用不一樣的日誌框架。api
建立工程,將 slf4j-api-1.7.13.jar 加入 class path , 如下程序編譯運行框架
import org.slf4j.Logger; import org.slf4j.LoggerFactory; public class HelloWorld { public static void main(String[] args) { Logger logger = LoggerFactory.getLogger(HelloWorld.class); logger.info("Hello World"); } }
控制檯輸出ui
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder". SLF4J: Defaulting to no-operation (NOP) logger implementation SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
可見單純的 slf4j 只是定義了一套接口,以及其餘日誌框架的轉接器
如今咱們爲 slf4j 綁定最簡單的實現,在 classpath 加入 slf4j-simple-1.7.13.jar
從新編譯運行,控制檯輸出:spa
0 [main] INFO HelloWorld - Hello World
log4j 1.2(一個普遍使用的日誌框架)版本的橋接器,你能夠將 log4j.jar 加入classpath.net
java.util.logging 的橋接器,JDK原生日誌框架插件
NOP 橋接器,靜默丟棄一切日誌設計
一個簡單實現的橋接器,該實現輸出全部事件到 System.err. 只有INFO以及高於該級別的消息被打印,在小型應用中它也許是有用的。
Jakarta Commons Logging 的橋接器. 這個橋接器將SLF4j全部日誌委派給 JCL
slf4j 的原生實現,logback 直接實現了 slf4j 的接口,所以使用 slf4j 與 logback 的搭配也暗示了嚴格的零內存計算溢出