0

バックグラウンド:

最近、特定の操作に適切な ClassLoader を設定し、操作が完了すると元の ClassLoader を復元するコードを実装しました。

例えば:

ClassLoader originalCL = Thread.currentThread().getContextClassLoader();
try {
    Thread.currentThread().setContextClassLoader(specialCL);
    // do operation here that requires 'specialCL'
} finally {
    Thread.currentThread().setContextClassLoader(originalCL);
}

ドキュメントによると、getContextClassLoader()返される null は 2 つのことを意味する可能性があります。1) システム CL または 2) sys CL の取得に失敗した場合は、ブートストラップ CL。

戻り値:この Thread のコンテキスト ClassLoader、またはシステム クラス ローダー (または、失敗した場合はブートストラップ クラス ローダー) を示す null

ドキュメントによるとsetContextClassLoader(Classloader cl)、null CL が提供されている場合は、1) システム CL、または 2) sys CL の設定に失敗した場合はブートストラップ CL のいずれかです。

cl - この Thread のコンテキスト ClassLoader、またはシステムクラスローダー (または、失敗した場合はブートストラップクラスローダー) を示す null


質問:

上記の try-finally-restore プログラミング モデルを使用すると、スレッド上で最初に使用したものとは異なる ClassLoader になる可能性はありますか?

例えば:

// start out with System CL

ClassLoader original = getContextClassLoader(); // returns null

Thread.currentThread().setContextClassLoader(otherCL);

Thread.currentThread().setContextClassLoader(original); // i.e. set to null
// setCCL() tries to set System CL... fails 
// setCCL() tries to set Bootstrap CL... succeeds

setContextClassLoader(null)Bootstrap CL で開始し、System CLを使用して復元しようとすると、この逆も当てはまります。どちらの場合も可能ですか?

4

1 に答える 1