log4j2でslf4jを使用する価値はありますか？質問する

さあ、slf4jの代わりにlog4j2 APIをプログラムしましょう

安全です: Log4j2 API は slf4j とまったく同じ保証を提供しますが、それ以上の機能も提供します。

Log4j2 自体が API と実装モジュールに分離されているため、SLF4J を使用する価値はなくなりました。

はい、選択肢を広く保つことは、エンジニアリングの優れた実践です。後で別のログ記録実装に変更したい場合もあります。

過去 10 年ほど、アプリケーションにこのような柔軟性を構築するには、SLF4J などのラッパー API を使用する必要がありました。ただし、この柔軟性は無料で得られるわけではありません。このアプローチの欠点は、アプリケーションが基盤となるログ ライブラリの豊富な機能セットを使用できないことです。

Log4j2 は、アプリケーションを最低限の共通基準に制限する必要のないソリューションを提供します。

エスケープバルブ: log4j-to-slf4j

Log4j2 にlog4j-to-slf4jはブリッジ モジュールが含まれています。Log4j2 API に対してコーディングされたアプリケーションは、いつでもバックエンド実装を任意の slf4j 準拠実装に切り替えることができます。

質問で述べたように、Log4j2 API を直接使用すると、slf4j などのラッパー API を使用する場合と比べて、より多くの機能が提供され、機能以外の利点もいくつかあります。

• メッセージAPI
• 遅延ログ用のラムダ
• 文字列だけでなく任意のオブジェクトをログに記録する
• ガベージフリー: 可能な限り可変引数の作成や文字列の作成を避ける
• CloseableThreadContext は、使用が終了したアイテムを MDC から自動的に削除します。

（見るSLF4J では利用できない 10 個の Log4j2 API 機能詳細については。）

アプリケーションは、ネイティブの Log4j2 コア実装にロックされることなく、Log4j2 API のこれらの豊富な機能を安全に使用できます。

SLF4J は依然として安全弁ですが、アプリケーションが SLF4J API に対してコーディングする必要がなくなったというだけです。

開示: 私は Log4j2 に貢献しています。

更新: Log4j2 API へのプログラミングによって、何らかの形で「ファサードのためのファサード」が導入されるという混乱があるようです。この点では、Log4j2 API と SLF4J の間に違いはありません。

どちらの API も、ネイティブ実装を使用する場合は 2 つの依存関係が必要で、非ネイティブ実装の場合は 4 つの依存関係が必要です。この点では、SLF4J と Log4j2 API は同じです。例: