ライブラリコードからログを記録する必要がありますか？

Javaライブラリを開発している場合、ライブラリのコード内からログステートメントを発行することをお勧めしますか？

ライブラリ内にログを記録すると、デバッグとトラブルシューティングがより透過的になります。ただし、一方で、ロギングステートメントでライブラリコードを散らかすのは好きではありません。考慮すべきパフォーマンスへの影響もありますか？

はい、そうすべきです。SLF4Jのようなロギングファサードを使用すると、特定のロギングフレームワークでユーザーに負担をかけることなく柔軟性が得られます。

広く配布されているコンポーネントおよびライブラリの作成者は、コンポーネントまたはライブラリのエンドユーザーにロギングフレームワークを課すことを回避するために、SLF4Jインターフェイスに対してコードを作成できます。したがって、エンドユーザーは、対応するslf4jバインディングをクラスパスに挿入することにより、デプロイメント時に目的のロギングフレームワークを選択できます。このアプローチは、シンプルで非常に堅牢であることが実証されています。

また、ユーザーがSLF4J jarを含まない場合（ユーザーガイドから）：

SLF4Jバージョン1.6.0以降、クラスパスでバインディングが見つからない場合、slf4j-apiはデフォルトですべてのログ要求を破棄する無操作の実装になります。

ロギングのパフォーマンスへの影響が心配な場合は、このSLF4J FAQエントリをご覧ください。考え方は、文字列をインラインに追加するのではなく、ログステートメントにパラメーターを提供することです。

次の2行では、まったく同じ出力が得られます。ただし、ロギングステートメントが無効になっている場合、2番目のフォームは1番目のフォームよりも少なくとも30倍優れています。

logger.debug("The new entry is "+entry+".");
logger.debug("The new entry is {}.", entry);

SLF4Jはもう1つのロギングファサードですか？

SLF4Jは概念的にはJCLと非常によく似ています。そのため、それはさらに別のロギングファサードと考えることができます。ただし、SLF4Jは設計がはるかに単純で、ほぼ間違いなく堅牢です。簡単に言えば、SLF4Jは、[Jakarta Commons Logging]を悩ますクラスローダーの問題を回避します。

はい、ライブラリコードからログを記録する必要があります。開発に役立つだけでなく、ライブラリを使用する人にとっても便利です。必要なログステートメントのみを表示するようにログレベルをいつでも設定できることを忘れないでください。同じことを行うことができます。

最近、オープンソースのORMツールであるMybatisを使用していました。正しいはずのクエリが結果を返さないという問題をデバッグしていました。これはパラメーター化されたクエリであり、Mybatisのライブラリコード内にログが記録されているため、オンにして実際のクエリが実行されているのを確認できました。2つのパラメーターを交換したことは簡単にわかりました。ライブラリにログインせずに、私はほぼ同じくらい早く問題を見つけることができなかったでしょう。