Kengo's blog

Technical articles about original projects, JVM, Static Analysis and JavaScript.

SLF4JとLogbackは2021年現在では積極採用しない方が良い

SLF4JとLogbackの中の人はここ数年活発ではないのでLog4j2などを代わりに使いましょう。

SLF4Jの活動は最近活発ではない

SLF4JはVCSとしてGitHubを利用しています。最後の変更が2020年2月最後のリリースが2019年12月となっていることからも、あまり活発ではないことが伺えます。

またBTSとしてJIRAを使っていますが、こちらもメンテナンスされていません。昨夏SLF4J-209が既にクローズ可能な状態であることSLF4J-186が修正可能であることなどをコメントしましたが、1年近く経った今もすべて返信がない状態です。

2020年12月にイシューを閉じていたりするので全く動きがないわけではないのですが、年間で22つ作成されたのに対して2つしか閉じられていないので、充分にメンテされているとは言い難い状況です。

f:id:eller:20210531193941p:plain
2021年5月31日時点での過去360日のイシュー消化状況

2021年6月2日追記:Java9リリース以降期待されていたJigsaw対応が入っている2.0(元々1.8だったもの)の安定版がずっと来ていないことも課題です。初回リリースである 1.8.0-alpha0 が2017年04月だったので、4年は経過しています。最新の 2.0.0-alpha1 は2019年10月のリリースで、未だα版ですが、モジュールを利用する場合は1.7は使えない(複数のモジュールが同一パッケージを提供できない)ため使わざるを得ない状況にあります。

メンテナーを増やすつもりはない?

2020年8月14日に ceki@qos.ch にメールを送り、メンテナーを増やすつもりはあるか、あるなら自分はこういった貢献ができますという意思を伝えたのですが、こちらもまだ返信がありません。

少数のメンバーがリリース権限を握っており、かつプロジェクトリーダーが連絡を取れない状態……と考えると、かつてのFindBugsプロジェクトの最後に非常に近い状況にある気がしています:

blog.kengo-toda.jp

Log4j 2が活発に活動しているのが幸い

ではSLF4JやLogbackに頼れないとして、どういった移行先があるのか。ロギングファサードないしロギングライブラリとしては、以下のような選択肢があります:

個人的にありがたいのはLog4j 2が活発なことです。Logbackを採用する理由として実行性能があったと記憶していますが、Log4j 2はLogbackと比べても高い性能を示しているとされています。lazy loggingflow tracingなども備えています。あと地味にLoggerインスタンス作るのが楽です:

// SLF4J
// http://www.slf4j.org/faq.html#declaration_pattern
private static final Logger logger = LoggerFactory.getLogger(MethodHandles.lookup().lookupClass());

// Log4j 2
// https://logging.apache.org/log4j/2.0/manual/api.html#Logger_Names
private static final Logger logger = LogManager.getLogger();

ログライブラリはプロジェクトによって要件も異なるでしょうし、必ずしもLog4j2が最適な選択肢とは限りませんが、一度試してみても良いのではないかと思います。

2021年6月2日追記:既にあるプロジェクトのSLF4JやLogback依存を今すぐに切らなければならない状況ではないと考えています。これから始めるプロジェクトでは積極採用するべきではないと思いますが、そうではない場合、特にモジュールを利用する予定がない場合(Java 8利用中など)はそのまま使い続ければいいかと思います。新規プロジェクトでモジュールを利用する場合は、更新頻度の低いα版に依存するリスクを受容できるのかどうか検討する必要があるでしょう。