私はIDoMagicインタフェースを実装するクラスFooを持っています。 Fooクラスはシステムクラスローダーによってロードされ、IDoMagicインターフェースは他のクラスローダー（Dynamic Classloader）でインターフェースをロードするサードパーティーのコンポーネントで定義されています。別のクラスローダからのインタフェースを持つクラスをロードする
Fooの新しいインスタンスを作成しようとすると、IDoMagicのNoClassDefFoundが表示されます。私はそれが別のクラスローダーによって読み込まれているからだと思います。
IはBridgeClassLoader（Guiceので使用されるものと同様）を作成しようとした後、システムクラスローダからロードクラスFoo及びIはIDoMagicためではなく、任意のせずに使用したものと思い、異なるクラスローダから他のすべてのクラスています成功。
周囲に道がありますか？
Javaのクラスローダー（CL）はデリゲート戦略で動作します。つまり、CLが最初に親に尋ねることを意味します。親は、クラスXの定義を知っているかどうかを親に問い合わせます。先祖または現在のクラスローダがXのクラス定義を知っていた場合、現在のクラスローダはそれぞれX.classファイルから定義をロードします。
システムクラスローダーによってクラスFooがロードされている場合は、システムCLまたはこのCLの親によってロードされる必要があるクラスFooも必要です。他のJARにIDoMagicが提供されているため、このJARファイルをクラスパス（java -cp ...またはjava -jar ...）に追加する必要があります。委任モデルのために、このCLの（壮大な）子であるCLは、いずれの親CLによってロードされたクラス定義にもアクセスすることになる。
カスタムCLでロードする必要がある場合は、FooをシステムCLでロードするのではなく、カスタムCLまたはこのCLの子をロードして、委任戦略を実行し、 の場合Fooがロード/インスタンス化されます。
共有クラスは、従属CLによって使用される共通のCLリスト/配列の一種に保持されるカスタム委任CLモデルがあります。依存クラスは共通CLの直接の子ではありませんが、どちらの子もタスクを実行できなかった場合に親に問い合わせる前に、共通のCLに呼び出しを委譲する委任CLの子です。ここでの一つの解決策は、このような構造であるかもしれない：
ここbootstrap CL
- system CL
- delegation CL
- common CL
- plugin CL
- plugin 1 CL
- plugin 2 CL
、CLは、それに含まれる共通CL（オブジェクト合成）にloadClass(...)とfindClass(...)の呼び出しを委任する必要があり、それが定義を見つけることができなかった場合にのみ委任彼の親にコールを委任する。これと同様still experimental class
この委譲ローダーでは、共通CL f.e.でIDoMagicをロードすることができます。 Fooクラスには、common CLの直接の子ではないプラグインローダーの1つが含まれています。ただし、これには、親に問い合わせる前に、delegation CLが共通のCLへのすべての呼び出しを先に伝播する必要があります。また、この委譲ローダーは、カスタムCL（未使用クラスのアンロード）の難しさの1つをより困難にするので、テーブルにいくらかのオーバーヘッドをもたらします。