ライブラリコードからログを記録する必要がありますか？
Java=ライブラリを開発している場合、ライブラリのコード内からログステートメントを発行することは良い習慣ですか？
ライブラリ内にログを記録すると、デバッグとトラブルシューティングがより透過的になります。ただし、その一方で、ライブラリコードをログステートメントで散らかすことは好きではありません。同様に考慮すべきパフォーマンスへの影響はありますか？
はい、そうすべきです。 SLF4J のようなロギングファサードを使用すると、特定のロギングフレームワークでユーザーに負担をかけることなく、柔軟性が得られます。
広く分散しているコンポーネントおよびライブラリの作成者は、コンポーネントまたはライブラリのエンドユーザーにロギングフレームワークを課すことを回避するために、SLF4Jインターフェースに対してコーディングすることができます。したがって、エンドユーザーはクラスパスに対応するslf4jバインディングを挿入することにより、デプロイメント時に必要なロギングフレームワークを選択できます。これは、既存のバインディングをクラスパス上の別のバインディングに置き換えてアプリケーションを再起動することで後で変更できます。このアプローチはシンプルで非常に堅牢であることが証明されています。
また、ユーザーがSLF4J jarを含めない場合（ ユーザーガイド から）：
SLF4Jバージョン1.6.0以降、クラスパスでバインディングが見つからない場合、slf4j-apiはデフォルトで操作なしの実装になり、すべてのログ要求が破棄されます。
ロギングのパフォーマンスへの影響が心配な場合は、 this SLF4J FAQ entry を確認してください。ログステートメントにパラメーターを追加するのではなく、文字列インライン：
次の2行は、まったく同じ出力を生成します。ただし、ロギングステートメントが無効になっている場合、2番目の形式は最初の形式よりも少なくとも30倍優れています。
logger.debug("The new entry is "+entry+"."); logger.debug("The new entry is {}.", entry);
SLF4Jは概念的にJCLに非常に似ています。そのため、それはさらに別の伐採ファサードと考えることができます。ただし、SLF4Jは設計がはるかに単純で、間違いなくより堅牢です。簡単に言えば、SLF4Jは[Jakarta Commons Logging]を悩ますクラスローダーの問題を回避します。
はい、ライブラリコードからログを記録する必要があります。それはあなたが開発するのを助けるだけでなく、ライブラリを使用する人々はそれが有用であると感じるでしょう。必要なログステートメントのみを表示するようにログレベルをいつでも設定できることに注意してください。ログレベルも同じことができます。
最近、オープンソースのORMツールである Mybatis を使用していました。正しいはずのクエリが結果を返さないという問題をデバッグしていました。これはパラメーター化されたクエリであり、Mybatisはそのライブラリコード内にログを記録しているため、これをオンにして実際のクエリが実行されていることを確認できました。 2つのパラメーターを交換したことは簡単にわかりました。ライブラリにログインしないと、問題をほぼ同時に見つけることができませんでした。