剛寫Java的開發者在需要日誌時,應該會知道有java.util.logging(簡稱JUL),接下來,使用某些開放原始碼專案,在應用程式啟動時,可能會看到日誌訊息抱怨找不到log4j.properties,撰寫程式碼時,卻是使用commons-logging的API,後來使用其他框架,發現它使用的是SLF4J的API、設定檔名稱是logback.xml,有天連到了Log4j官網,竟然又看到了Log4j2?

混亂的歷史

就現今語言來說,本身內建日誌程式庫是個基本需求,一般來說,總是建議使用標準API,避免對第三方程式庫的依賴,然而在Java這塊談到內建的日誌程式庫,稍有經驗的開發者總是搖搖頭,過去有段很長的時候,他們會告訴你「使用Log4j」。

Java標準程式庫一開始並沒有JUL,在第三方程式庫的實現,Ceki Gülcü創建的Log4j受到廣泛使用,雖然如此,當時Java擁有者的Sun並不接受Log4j,而在JDK1.4中放入JUL,然而,因為功能比Log4j簡單,而且初期又有效能不彰等問題(在JDK1.5才有了改善),於是,開發者仍建議使用Log4j。

無論如何,Java界現在有了受歡迎的Log4j,以及標準內建的JUL,總會遇到要做出選擇,以及處理不同日誌程式庫的問題。當時出現的Jakarta Commons Logging(後來改名為Apache Commons Logging),定義了一層介面(本身有個簡易SimpleLog實現),可以動態地綁定JUL或者是Log4j,作為日誌實現,開發者使用commons-logging的API,不需要依賴在JUL或是Log4j的程式碼。

然而,commons-logging的動態綁定有著規則複雜等問題,Log4j本身也有些效能議題,因此,Log4j的創建者Ceki Gülcü後來開發了SLF4J,全名Simple Logging Facade for Java。顧名思義,SLF4J也是定義一組介面,實作上可以綁定Log4j、JUL,或者是Ceki Gülcü實現的Logback。SLF4J也提供了橋接套件,只要使用對應的JAR,就可以替換掉Log4j、JUL或commons-logging,然而現有的程式碼不用更改,底層實際上卻使用SLF4J。

這一切Log4J的維護團隊看在眼裏,後來,他們吸收了SLF4J、Logback的經驗與優點,在2014年正式推出了Log4j2,也採取了介面與實現分離的設計(分為Log4j2 API與Log4j2 Core),在效能上有很大的提升,還提供了非同步日誌等功能;而Log4j於2012年發布最後一個版本之後,也在2015年正式宣布終止。

認識實作品

日誌程式庫在實作品的設計上,基本概念是類似的,例如Log4j中的Logger、Appender、Layout等概念,在JUL中換成了Logger、Handler、Formatter之類的角色,這部份可參考先前專欄〈從日誌API認識日誌需求〉;認識Logger、Appender等概念,以及它們之間的組合關係,主要是知道如何在日誌設定檔中,組合出應用程式的日誌需求,而不是在程式碼中調整,也因此,認識日誌實作品的重要任務之一,就是知道如何撰寫設定檔,以及是否可彈性地選擇設定檔。

不過,JUL最令人詬病的地方,就是設定檔只能是.properties,而且,只能透過java.util.logging.config.file,指定.properties的位置。相對地,Log4j、Logback、Log4j2 Core都可以有不同的設定檔格式,像是.properties、XML、Groovy(Logback),或是JSON(Log4j2,然而Log4j2不支援.properties)等,也可以有多個設定檔來源。如果可以依賴在介面,就不要依賴在實作,因此,程式碼撰寫上。建議使用commons-logging、SLF4J,或者是Log4j2 API,透過設定檔等方式來決定使用哪個實作品。

commons-logging在尋找實作品上,有著一套複雜的規則,才能決定最後要使用Log4j、JUL或者自身的SimpleLog(輸出至System.err),由於其動態綁定是基於ClassLoader實現,在自定義ClassLoader的環境中,會引發NoClassDefFoundError等問題(詳見Ceki Gülcü的文件:https://goo.gl/e2CTRN)。

SLF4採用靜態綁定的方式,具體來說,類別路徑下,只能有一個對應的SLF4J綁定(SLF4J bindings),例如,若底層想要用Log4j,可以使用slf4j-log4j12的JAR檔案,而且,各個綁定的JAR中,都有org.slf4j.impl.StaticLoggerBinder綁定實作品,如果想更換日誌實作,只要更換JAR檔案。

至於在不修改程式碼下,就可以將既有的日誌輸出橋接至SLF4的方式,則是使用直接實作了Log4j、JUL或commons-logging的JAR檔案,來替換,例如,想將原本使用commons-logging的日誌橋接至SLF4J,在最簡單的情況下,只要將commons-logging.jar,替換為jcl-over-slf4j.jar,就可以了。

如果不想修改程式碼,又想要令使用Log4j的應用程式可以獲得Log4j2 Core的效能改進,可以使用Log4j2的log4j-1.2-api.jar,將log4j的JAR替換掉(以及額外的三點要求,詳見https://goo.gl/CG5cjb)。

API上的著墨

在撰寫程式碼進行輸出日誌時,基本上,都是透過一個工廠類別的靜態方法取得Logger實例,然後呼叫對應的等級方法進行輸出。不過,還是有些可以留意的部份。例如Ceki Gülcü認為,有些日誌API容易讓開發者寫出錯誤的日誌輸出,像是commons-logging的warn、info等方法接受的是Object,開發者可能隨意傳入物件,因而容易忘了思考與定義該輸出的日誌訊息為何,SLF4J的warn、info等方法強制要傳入String物件來避免這類問題。

在〈LOGBack: Evolving Java Logging〉(https://goo.gl/CqtbJj)中Ceki Gülcü也談到,有些日誌程式庫可能會使用字串串接方式組成訊息,例如:

if(logger.isDebugEnabled()) {
logger.debug("User with account " + user.getAccount() +
" failed authentication; supplied crypted password " + user.crypt(password) +
" does not match." );
}

可以看出字串串接上極為麻煩,而為了避免字串串接上的開銷,必須使用isDebugEnabled()來判斷,SLF4J可以採用字串模板的方式來解決:

logger.debug("User with account {} failed authentication; supplied crypted password {} does not match.",
user.getAccount(), user.crypt(password));

這樣的設計也被Log4j2吸收;至於JDK本身的JUL,儘管常被建議不要使用,實際上,本身仍在改善,若日誌動作比較消耗資源,在JDK8可撰寫為:

logger.debug(() ->; expensive());

這帶入了Lambda語法,讓語法簡潔許多,而實際上,expensive()只在層級為Debug時才會執行,不必特別使用isLoggable()判斷,也避免不必要的開銷。

認識日誌程式庫歷史

從歷史的發展時間來看,這邊談到的日誌程式庫,大致上的順序為Log4j -> JUL -> [commons-logging] -> [SLF4J]/LogBack -> [Log4j2 API]/Log4j2 Core,[]部份表示介面定義,可以的話,使用日誌時應該透過這些介面,而SLF4J看來可以替代commons-logging,它的橋接設計,可以靈活地替換各種實作品,也可以橋接至Log4j2,無論是直接使用,用來整合多個日誌方案,或者用來逐步改造既有程式的日誌,會是個不錯選擇。

然而,實際的情況可能更複雜,好好檢視日誌程式庫的發展歷史,仍是必要的,網路上雖然也有許多的比較文章,不過,試著自行疏理、動手實作,或者改造幾個簡單專案的日誌,會更能瞭解這些程式庫之間錯綜複雜的關係,以便做出更好的選擇。

作者簡介


Advertisement

更多 iThome相關內容