発展しつつあるJavaのロギング

作者 Geoffrey Wiseman , 翻訳者 佐野 徹郎 投稿日 2007年9月4日

セクション

デベロップメント

トピック

Java

タグ

Logging

Ceki Gulcu氏はJavaのロギングの世界で良く知られている。彼は、JREの中のロギングに含まれていないにもかかわらず、非常に人気のある独自のJavaのロギングフレームワークである、Log4Jを創設した。彼は次にJakarta commons-loggingからSLF4J(Simple Logging Facade for Java)への置き換えに取りかかった。

昨年中、Cekiが取り組んだ新しいプロジェクト「信頼でき、ジェネリックで、高速かつフレキシブルな、Javaのためのロギングフレームワーク」LOGBackは、ちょうど1年以上前に0.1アルファをリリースしてから、勢いを増しつつある。

Xavier Hanin氏は彼のLOGBackの経験について述べた。

リリース間近の1.0と採用者のなかなか好意的な批評は、LOGBackに注目し、それがあなたにとって役に立つかを確かめる、よい時期ということかもしれない。

私は現在、数ヶ月LOGBackを利用しています。そして私は感心しました！

素晴らしいドキュメンテーションとサポート、すっきりしたロギング機能、非常に優れたパフォーマンスと革新的なEclipseプラグイン。私はついに古き良きLog4jの優れた後継者を見つけました。

Rob Willams氏は付け加える。

私たちも思い切ってLogBackを利用してみました。これは素晴らしいです。面倒な切り替えのない、とても素晴らしい置き換えの構文です。

彼が言及している置き換えの構文は、ごくわずかなパフォーマンスへの影響のためにロギングレベルのチェックで取り囲むことなく、LOGBackが多くの複雑なロギングステートメントを受け入れることを可能にする。

if( logger.isDebugEnabled() ) {
  logger.debug( "User with account " + 
    user.getAccount() + " failed authentication; " +
    "supplied crypted password " + user.crypt(password) +
    " does not match." );
}

例えばLog4Jなら以下のように書くだろう。

logger.debug( "User with account {} failed authentication; " +
    "supplied crypted password {} does not match.",
    user.getAccount(), user.crypt(password) );

の例で、メッセージを組み立てるコストはLOGBackがこのメッセージを表示するかどうか確定するまで延期されるが、暗号化パスワードのような高価なパラメータを取り出すコストは延期されない。

LOGBackはパフォーマンスも優れているという。

例えば、ログステートメントを記録するかどうかを確定するような、クリティカルな操作はかなり改善されました。この操作に、LOGBackではおよそ3ナノ秒かかるのに対して、Log4jでは30ナノ秒かかります。LOGBackはロガーの生成も高速です。Log4jの23マイクロ秒に対して、13マイクロ秒です。さらにすごいのは、既存のロガーを取ってくるのに、Log4jは2234ナノ秒なのに対して、94ナノ秒で23倍も高速なのです。JUL(java.util.logging)における改善も決してわずかなものではありません。LOGBackはEclipseプラグインやJMX MBeanとも統合されている。

InfoQはCeki氏にLOGBackについて考慮することの多くを質問した。なぜLog4jを変更せずに別のロギングフレームワークを開発するのか？

私は当時(今でもある程度)、Apache Logging Services projectの外側に導入するほうが簡単だと信じていました。誤解しないでほしいのですが、Apache Software Foundationはユニークないろいろな意味で素晴らしい組織で、私はとても高く評価しています。もしかすると、いつかSLF4JとLOGBackがロギングの新しいデファクトスタンダードとして認められたら、Apacheに統合されるかもしれません。

SLF4Jの採用について。

Hibernate、Jetty、Spring-OSGIやWicketなどの最上級のプロジェクトがSLF4Jに移行したことで、率直に言ってSLF4Jはかなり広まりつつあります。すでにJCL(Jakarta Commons Logging)がApacheブランドの庇護の下でマーケットを独占しているにもかかわらず、SLF4Jはあらゆるところに出現しています。後発という不利な状況からすれば、SLF4Jは当初の予想よりうまくいっています。 ご指摘のとおり、Log4jは限られたフリードキュメンテーションのみを提供し、きちんとしたドキュメンテーションの利用は有料です。

Log4Jの限られたフリードキュメンテーションと多くの商用ドキュメンテーションという方法と、LOGBackのフリードキュメンテーションとの比較について尋ねた。

ご指摘のとおり、Log4jは限られたフリードキュメンテーションのみを提供し、きちんとしたドキュメンテーションの利用は有料です。LOGBackで私たちは、すべてのドキュメンテーションを利用しやすくすることで、Javaの開発者をLOGBackに切り替えさせるために、無償でプロジェクトのサイトに置くという方法を採用しました。それに、LOGBackのマーケットシェアはLog4jよりも桁違いに小さいのです。LOGBackにとってはドキュメンテーションを販売することに経済的な意味はないでしょう。

長期にわたるプロジェクトの経済的な持続性のために、私たちはLOGBackと緩やかに関連するプロダクトを開発しました。それは数週間のうちに明らかになるでしょう。私たちの長期にわたる計画は、LOGBackが策略を用いずオープンソースプロジェクトと協力して開発されることを求めています。協力することで、現在の開発者グループの外側の開発者から貢献を得られるということです。

1.0をリリースするのに、さらに何が必要か述べている。

来るべき1.0のリリースのために、必要な大部分はすでにあります。 私たちはいくつかのバグも修正しなければなりませんが、ほとんどはドキュメンテーションを改善し、さらなるテスティングを立ち上げ繰り返すことです。私はより良いドキュメンテーションについて話しましたか？

ロギングの分野にはまだやるべきことが、一生続けられるかもしれないくらい、たくさんあります。私たちには、比較的はっきりした前途の見通しと、いくつかの道を切り開く希望があります。

開発者にとってLOGBackに切り替えねばならない理由は何か尋ねた。

明確な答えはありません。一部のユーザにとってはパフォーマンスが切り替えるべき理由になるかもしれませんが、一方でLog4jに満足しているユーザもいます。私と他のLOGBackの開発者は切り替えるべき理由をユーザに提供する努力をしていますが、私たちの多くは品質を重視するソフトウェアプロジェクトに取り組むだけで幸せです。私たち自身はLOGBackによって、今日のスタンダードのような損益のない、有益なソフトウェア開発スキルを手に入れました。Log4jの利用を止めたところがLOGBackを取り上げるなら、LOGBackの継続的な評価のために改善を続けてさえいれば、SLF4JとLOGBackの組み合わせを採用するJavaの開発者は増えていくと、私たちは信じています。

SLF4JとLOGBackは競合するAPIをブリッジできるので、開発者は自身のプロジェクトでLog4J(log4j-bridge.jarによっ て)とJakarta Commons-Logging(jcl104-over-slf4j.jarによって)をLOGBackに置き換えて、LOGBackを利用するために 1つのプロジェクトで2つ以上のロギングフレームワークを設定するのを避けることができる。

LOGBackとSLF4Jのさらなる情報は、Cekiが提示する「LOGBackに切り替える10の理由」を読むか、InfoQのJavaコミュニティに注目してほしい。

• 次へ >