デイブ・サイアー (SpringSource)書く彼のブログではこう述べています。
残念ながら、commons-logging の最悪な点、そして新しいツールで不評を買っている原因は、ランタイム検出アルゴリズムです。
なぜですか? ランタイム検出アルゴリズムの問題は何ですか? パフォーマンスですか?
ベストアンサー1
なぜですか? ランタイム検出アルゴリズムの問題は何ですか? パフォーマンスですか?
いいえ、パフォーマンスではありません。クラスローダーの苦痛JCL検出プロセスは、実行時にロギングフレームワークを見つけるためにクラスローダーハックに依存していますが、このメカニズムは、予期しない動作、デバッグが困難なクラスローディングの問題など、多くの問題を引き起こし、複雑さが増します。これは、Ceki（Log4J、SLF4J、Logbackの作者）によってうまく表現されています。commons-logging APIを採用する前にもう一度考えてみましょう(JCL で観察されるメモリ リークの問題についても言及されています)。
これが、静的バインディングを使用する SLF4J が作成された理由です。
Ceki は SLF4J の著者なので、彼の記事は偏っていると思うかもしれませんが、信じてください、偏っていません。彼は自分の主張を証明するために多くの参考文献 (証拠) を提供しています。
総括する：
- はい、JCL は壊れていることが知られているので、使用しない方がよいでしょう。
- ロギング ファサードを使用する場合 (すべてのプロジェクトで必要なわけではありません)、SLF4J を使用します。
- SLF4J は、Spring のようにまだ JCL を使用しているフレームワークに JCL から SLF4J へのブリッジを提供します :(
- Log4J の後継である Logback は、優れたログ記録実装だと思います。
- Logback は SLF4J API をネイティブに実装しています。つまり、Logback を使用している場合は、実際には SLF4J API を使用していることになります。