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

log4j2でslf4jを使用するかどうかを決定できません。オンライン投稿に基づくと、パフォーマンスに影響があるようには見えませんが、本当に必要ですか？

また、これらの点は、log4j2を支持するものです。

• SLF4Jはアプリケーションに文字列のログを強制します。Log4j 2 APIは、テキストをログに記録する場合、CharSequenceのロギングをサポートしますが、オブジェクトをそのままロギングすることもサポートします。
• Log4j 2 APIは、メッセージオブジェクトのロギング、Java 8ラムダ式、ガベージフリーロギングのサポートを提供します（可変引数配列の作成を回避し、CharSequenceオブジェクトのロギング時に文字列の作成を回避します）。

先に進む：slf4jの代わりにlog4j2 APIにプログラムする

安全です。Log4j2APIは、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は同じです。例えば：