3

java.util.logging.LoggerクラスはResourceBundle、非常に特殊な方法でインスタンスを検索します。クラスローディングの動作を理解することに興味があります。

キャッシングなどを破棄して、最初にクラスはコンテキストクラスローダーLoggerを使用しようとします（これは適切であり、私が期待することです）。

そのクラスローダーが（呼び出しResourceBundleを使用して）ロードできない場合は、次にシステムクラスローダーが使用されます。それは私には少し戸惑いました。呼び出し元のクラスローダーが次のクラスローダーになると思います。これは最適化ですか、それとも特定のユースケースを処理するためのものですか、それとも...？ResourceBundle#getBundle(String, Locale, ClassLoader)

最後に、システムクラスローダーがをロードできない場合ResourceBundle、推測された呼び出しスタック（！）がウォークされ、そのスタック内の各クラスがそのクラスローダー用にマイニングされ、それぞれが順番に試行されます。

私が遭遇した、または書かなければならなかったさまざまなクラスローディングシナリオのすべてについて、これは私にとって最も意味がありません。これはLogger、特定のシステムに対する潜在的な中心性に関係していると思いますが、この特定のアルゴリズムが選択された理由についての説明を歓迎します。

（また、それ自体のエントリに実際には価値のない副次的な質問：コンテキストクラスローダーが存在するJVMの状況はありnullますか？）

4

1 に答える 1

1

私の推測では、彼らは、J2EE クラスローダ階層と、各アプリケーション サーバーでのさまざまな実装をサポートする方法を考えていたのでしょう。

さらに、JavaDocを確認すると、

初期実装の一時的な移行機能として、Logger が ContextClassLoader または SystemClassLoader から ResourceBundle を見つけることができない場合、Logger はクラス スタックも検索し、連続して呼び出している ClassLoader を使用して ResourceBundle を見つけようとします。(このコール スタック検索は、コンテナーが ContextClassLoaders を使用するように移行できるようにするためのものであり、将来のバージョンでは削除される可能性があります。 )

于 2013-03-06T11:49:22.150 に答える