1

OSGiは、OSGi カスタム クラスローダーを使用してバンドルからロードされたクラスを rt.jar からロードされたクラスにキャストするという問題1をどのように解決しますか? rt.jar は、システム クラスローダの代わりにカスタム クラスローダもロードしますか?

UPD1

ClassLoader.java の次のコードのため、カスタム クラスローダーを使用して rt.jar のほとんどの部分をロードできないようです。

private ProtectionDomain preDefineClass(String name, ProtectionDomain protectionDomain) {
    ...
    if ((name != null) && name.startsWith("java.")) {
        throw new SecurityException("Prohibited package name: " +
        name.substring(0, name.lastIndexOf('.')));
    }
    ...
}

[1] 問題は次のとおりです。異なるクラスローダーでロードされたクラスは、バイトコードがまったく同じであってもrt.jar!/SomeClass、jvm によってまったく異なるものとして扱われます。異なるクラスローダーによってロードされた場合、にbundle.jar!/SomeClassChildキャストできません。SomeClassChildSomeClass

4

2 に答える 2

4

Java ではそのような問題はありません。確かに、質問に記載されているとおりではありません。異なるクラスローダーによってロードされた同じ名前のクラスが同じクラスとして扱われないことは事実ですが、このことから、スーパークラスがサブクラスと同じクラスローダーによってロードされなければならないということにはなりません。

実際、Object を含むすべての java.* クラスはブートストラップ クラスローダから取得され、アプリケーション内のユーザー クラスはブートストラップ クラスローダによってロードされないため、OSGi が登場するずっと前に、Object に何かをキャストすることさえ不可能でした。 .

于 2012-05-19T13:16:20.103 に答える
1
  • java.* クラスは特別です... Java 仕様では、「java.」で始まるすべてのクラスが必要です。セキュリティ上の理由から、ブート クラス パスからロードされます。
  • rt.jar のその他のクラス (パッケージも含む) は、フレームワーク自体によってエクスポートされます。すべてのフレームワークには一連のデフォルトがありますが、これらのデフォルトを拡張できるプロパティがあります (org.osgi.framework.system.packages[.extra])。フレームワークは、フレームワークをロードしたクラスローダーから、または起動プロパティに基づいてブート クラス ローダーから、これらのパッケージのクラスをロードします。

その魔法は、OSGi フレームワークがそれらすべてのパッケージをクラスローダーのメッシュにつなぎ合わせて、複数のクラスローダーが同じクラス名をロードできる場合でも、各バンドルが競合のない一貫したクラス空間を確認できるようにすることです。したがって、OSGi では、適切なメタデータがあり、クラス ローディング ハックがなければ、クラス キャスト例外は発生しません。

2 つのバンドルが同じパッケージ名の異なるクラス ローダーにバインドされている場合、OSGi フレームワークは、これらのバンドルが異なるクラス スペースに存在するため、これらのバンドルが相互に認識されないようにします。

于 2013-05-20T07:31:01.660 に答える