回答:
おそらく、util.loggingを使用して、説明したニーズに対応できます。
適切な決定木については、Log4jとjava.util.loggingをご覧ください。
質問1：SMTPHandler、NTEventLogHandler、または非常に便利なFileHandlerなど、JULにはないLog4jの巧妙なハンドラーの必要性を予想していますか？
質問2：ログ出力の形式を頻繁に切り替えたいと思っていますか？簡単で柔軟な方法が必要ですか？つまり、Log4jのPatternLayoutが必要ですか？
質問3：アプリケーションの複雑なロギング設定をコンパイルして本番環境にデプロイした後、それらを変更する機能の明確な必要性を予期していますか？「このクラスからの重大なメッセージは電子メールでサポート担当者に送信されます。クラスのサブセットからの重大なメッセージはサーバー上のsyslogデーモンに記録されます。クラスの別のサブセットからの警告メッセージは記録されます。ネットワークドライブAのファイルに保存すると、どこからでもすべてのメッセージがネットワークドライブBのファイルに記録されます。そして、あなたは自分が数日ごとにそれを微調整しているのを見ますか？
上記の質問のいずれかに「はい」と答えられる場合は、Log4jを使用してください。それらすべてに対して明確な「いいえ」と答えると、JULは十分すぎるほどで、SDKに既に含まれているので便利です。
そうは言っても、他のいくつかのライブラリーが使用しているからといって、最近のほとんどすべてのプロジェクトはlog4jを含めて終了するようです。
Simple Logging Facade for Java（SLF4J）を使用することをお勧めします。Log4Jを含むさまざまなプロバイダーをサポートし、Apache Commons Loggingの代替として使用できます。
Log4jは長い間使用されており、非常にうまく機能します。私にはそれを裏付ける科学的研究はありませんが、私が多数のクライアントで見たものに基づいて、私が他の何よりも多く使用しているのを見るのは簡単にロギングフレームワークです。それは長い間存在しており、何かを言うNext Big Logging Frameworkに取って代わられていません。
設定は非常に簡単で、基本的なアペンダー（出力）を簡単に学ぶことができます。次のものを含む、利用可能なホストアペンダー全体があります。
プラス他。独自のアペンダーを作成することも難しくありません。さらに、ログに出力される内容を具体的に制御できるように、各アペンダーには大きな柔軟性があります。
1つのメモとして、log4jに加えてApache Commons Loggingを使用すると、一連のクラスローダーの問題が発生しました。これは特定の1つのアプリケーションのみを対象としたものですが、コモンズロギングなどの抽象化レイヤーを使用する場合に柔軟性を提供するよりも、log4jを単独で使用する方が簡単であることがわかりました。
詳細については、この記事を 参照してください。
幸運を！
java.util.loggingは、他のいくつかが提供する過剰な手荷物なしで包括的なロギングパッケージを提供します。
log4jは全体的にはるかに優れたパッケージであり、java.util.loggingに含まれている問題の一部がありません。第二に、logsjを直接使用する方が、commonsロギングを使用するよりも簡単です。
ロギングインターフェイスとしてApache Commmons Loggingを使用することをお勧めします。これにより、コードの変更を必要とせずに、いつでもロギングの実装を柔軟に切り替えることができます。