SLF4J(Java 用のシンプルなロギング ファサード) は、多くのロギング フレームワークへの汎用アクセスを提供するように設計された API であり、log4j もその 1 つです。
基本的には抽象化レイヤーです。これはロギングの実装ではありません。これは、あなたがライブラリを作成していて SLF4J を使用している場合、そのライブラリを他の人に渡して使用させることができ、その人は SLF4J で使用するロギング実装 (log4j や Java ロギング API など) を選択できることを意味します。これは、アプリケーションがさまざまなロギング API に依存するライブラリを使用するのと同じように、それらに依存することを防ぐために使用されます。
ただし、たった 1 行の回答に値する Log4J と SLF4J の違いについて詳しく説明します。つまり、質問自体が間違っています。 SLF4J と Log4J は異なるか、似たコンポーネントではありません。名前が指定されているように、SLF4J は Java 用の単純なロギング機能です。これはログ記録コンポーネントではなく、実際のログ記録も行いません。これは、基礎となるロギング コンポーネントに対する抽象化レイヤーにすぎません。
の場合 Log4j 、これはロギングコンポーネントであり、指示されたロギングを実行します。したがって、SLF4J と Log4J は論理的には 2 つの異なるものであると言えます。
あとは、実行時にどのロギング フレームワークを使用するかを選択するだけです。そのためには、2 つの jar ファイルを含める必要があります。
- SLF4J バインディング jar ファイル
- 必要なロギング フレームワークの jar ファイル
たとえば、プロジェクトで log4j を使用するには、以下の jar ファイルを含める必要があります。
- slf4j-log4j12-1.7.12.jar
- log4j-1.2.17.jar
両方の jar ファイルをアプリケーションのクラスパスに配置すると、SLF4J はそれを自動的に検出し、log4j 構成ファイルで指定した構成に基づいてログ ステートメントの処理に log4j の使用を開始します。
たとえば、プロジェクト クラス ファイルに次のコードを記述できます。
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'); } } SLF4J が Log4J よりも優れているのはなぜですか?
SLF4J と Log4j のどちらを優先するかは常に困難です。選択肢があるなら、私はあなたを勧めます。ロギング抽象化は常にロギング フレームワークよりも優先されます。ロギング抽象化、特に SLF4J を使用する場合、単一の依存関係を選択することなく、デプロイメント時に必要なロギング フレームワークに移行できます。
Log4j ではなく SLF4J を選択するのに十分な理由は次のとおりです。
- 常に抽象化を使用することをお勧めします。
- SLF4J は、特定のログ実装から独立したオープンソース ライブラリまたは内部ライブラリです。つまり、複数のライブラリの複数のログ設定を管理する必要がありません。
- SLF4J は、プレースホルダー ベースのロギングを提供します。これにより、isInforEnabled()、isDebugEnabled() などのチェックが削除され、コードの可読性が向上します。
- SLF4J のロギング メソッドを使用することにより、ロギング メッセージ (文字列) の構築コストが必要になるまで延期され、CPU とメモリの両方が効率的になります。
- SLF4J は使用する一時文字列の数が少ないため、ガベージ コレクターの作業が減り、アプリケーションのスループットとパフォーマンスが向上します。
したがって、基本的に、SLF4J は log4j を置き換えるものではありません。彼らは両方とも一緒に働きます。これにより、アプリケーションから log4j への依存関係が削除され、将来的にはより高性能なライブラリに簡単に置き換えることができるようになります。