Apache Software Foundationは先日，Log4j 2.0の提供開始を発表した。前バージョンのLog4.j 1.xに対して大幅にパフォーマンスが向上する。開発に数年を費やした今回のリリースは，Log4j 1.xやjava.util.loggingといった既存のロギングソリューションの影響を受けて，スクラッチから書き直されたものだ。
Log4j 2.0では新たにプラグインシステムやプロパティのサポート，JSONベースのコンフィギュレーションのサポート，コンフィギュレーションの自動再ロードなどが導入される。さらにはSLF4JやCommons Logging, Apache Flume, そしてLog4j 1.xなど，既存のロギングフレームワークの多くをサポートし，新たにプログラマ用APIも提供する。
Apache Logging PMCメンバのChristian Grobmeier氏は，2012年12月，この新しいLog4j 2.0を始めて紹介した記事の中で，新たなAPIを次のように説明している。
これまでは，以下のような記述が必要でした。
if (logger.isDebugEnabled()) { logger.debug("Hi, " + u.getA() + " " + u.getB()); }Log4j 2.0チームは，このような場合を検討してAPIを改良しました。これと同じ処理が，次のように記述可能になります。
logger.debug("Hi, {} {}", u.getA(), u.getB());
Grobmeier氏は，MarkerやFlow TracingといったAPI改良の説明を続けた上で，プラグインアーキテクチャの改良やコンフィギュレーションの拡張(ホットローディング，JSON, プロパティを使用した)，そしてLog4j 1.xにあった多数のデッドロック問題への対処方法についても言及している。
Hacker Newsには，JVM用ロギングフレームワークの急増に対する不満の声が多数上がっている。Log4j, SLF4J, Logbackなど多数のロギングフレームワークの作者であるCeki Gülcü氏は，自身がApacheモデルを好まない理由を説明する。Gülcü氏は現在もコミュニティのメンバであり，Apache LoggingのPMCを続けている。
2013年7月にGrobmeier氏は，新たに“Log4j 2: Performance close to insane”と題する記事を執筆した。その中で氏はRemko Popma氏の“AsyncLoggers”を取り上げて，他フレームワークの12倍以上のロギングスループットを実現した，と絶賛している。
他のフレームワークが毎秒1,500,000程度かそれ以下の環境と同じ条件で，毎秒18,000,000メッセージが可能というのです。
チャートを見ても，すぐには信じられませんでした。何かのまちがいではないのか，もう一度確認しました。自分でテストも実行してみました。その結果，Log4j 2はとにかく速い，ということが分かったのです。
詳細な情報は，Log4jの非同期に関するドキュメントで確認してほしい。
しかしながら，Log4jの非同期機能に誰もが感激している訳ではない。FullContactのシニアプラットフォームエンジニアであるMichael Rose氏は，“Overengineering: Log4j2's AsyncAppender”というブログを書いて，この機能は利用に値しないものだ，と切り捨てている。
結論として，Log4j2のAsyncAppenderは素晴らしくても，単なる見栄えのいいおもちゃであって，現実のアプリケーションでの差はほとんどないのです。Log4j2チームには最大限の敬意を払います。ですが彼らには，またひとつロギングフレームワークを増やして混乱を増長するよりも，ひとつに凝縮された次世代Javaロギングフレームワークの開発に注力してほしいと思っています。
しかしLoopbackは，SLF4J(クラスパス結合ロギングのデファクト標準)のネイティブな実装なのですが，パフォーマンスの面では十分過ぎるくらいです(特にロケーションをオンにした場合には)。私はずっと，このロギングフレームワークを使い続けています。使いやすいですし，利用していて問題にぶつかったこともありません。
少なくともLog4j 1.x(あるいはLog4j2とLogback以外のものはすべて)は使わない方がよいでしょう。負荷の高いシステムで使用していると，いずれ競合問題が発生しますから。
Log4j 1.xから2.0への移行
筆者は先日，自身のAppFuseアプリケーションをLog4.j 1.xを2.0にアップグレードしたところ，Mavenの依存関係の適切な設定が難しいと感じた。最低限として必要なのはlog4j-core JAR(これはlog4j APIに依存している)である。Wepアプリを使っているならば，依存対象としてlog4j-webも必要だ。Velocity 1.7をLog4j 2と同時に使用したければ，log4j-1.2-apiも必要になる。Springを使用するなら，log4j-jclも追加しなければならない(commons-loggingを使用するため)。SLF4Jに依存するライブラリならば，log4j-slf4j-implが必須だ。筆者はHibernateでLog4j 2.0を動作させるために，JBoss Logging 3.2.0.Beta1にアップグレードしなければならなかった。
いくつかの依存定義から，古いLog4jへの依存性を取り除く必要があるかも知れない。Mavenを使用しているのならば，次のコマンドを実行して，削除の必要な依存性を確認するとよいだろう。
mvn dependency:tree | grep log
最終段階として必要なのは，log4j.xmlをlog4j2.xmlにリネームして，新しいコンフィギュレーションに合うようにリファクタする作業だ。
要約
新しいLog4j 2.0リリースには多くの部分でのパフォーマンス向上，新たなプラグインシステムに加えて，コンフィギュレーション設定が数多く改良されている。しかしこれらの拡張機能に対して，アップグレードや既存のロギングソリューションから移行する価値があるかどうかはユーザ次第だろう。