2 に答える
前の回答へのいくつかの追加：
InnerClasses 属性は、含まれる内部/ネストされたクラスを含むクラスに格納するために使用されますか?それとも、「コンテナー」クラスを参照するために内部/ネストされたクラスで使用されますか?
コンパイルされたすべてのクラスのバイトコードは、個別の .class ファイルに格納されます。実際の「内部クラス」はその属性に格納されません。以前の投稿で指摘したように、その属性は、バイトコードの作成時にコンパイラが認識していたクラスのみを指します。
クラス ファイルの InnerClasses 属性は十分ですか? たとえば、内部/ネストされたクラスは $ でマングリングする名前に従う必要がありますか、それともこれは単なる慣習ですか?
InnerClasses 属性を設定せずにクラスを内部/ネストされたクラスのように JVM に見せる方法はありますか?これは JLM ベンダーに依存しますか? (IBM の実装では、一部の要件がそれほど厳密ではなかったと聞いたのを覚えています。)
どちらの質問についても、よくわかりません。しかし、内部/ネストされたクラスの概念は、Java 言語 (したがって Java コンパイラーが提供するもの) のものだと思います。バイトコードでは、通常のパブリック クラスとして宣言されたクラスと、ネストされたクラスまたは内部クラスとの間に違いがあってはなりません。次のように、特定の VM がこれをどのように処理するかを簡単に試すことができます。
- いくつかのネストされた内部クラスを持つクラスを作成します
- クラス定義のスコープ外からのリフレクションを通じて、内部クラスの 1 つをロードしてインスタンス化しようとする小さなプログラムを作成します。ここではリフレクションを使用する必要があります。Java コンパイラでは、スコープ外のネストされたクラスをインスタンス化できないためです。クラスを正常にインスタンス化できる場合、それは、VM がネストされたクラスと通常のクラスを内部的に異なる方法で処理しないことの証拠です。
JVM のクラス ローディング メカニズムは、Java リフレクションとどの程度相互作用しますか? JVM が Java リフレクションの結果と一致しないようにすることは可能でしょうか?
この最後の質問がわかりません。VM とリフレクションが一致しないと言うときの意味をもう少し説明していただけますか?
クラスファイルに内部クラス属性があることは知っていますが、これで十分ですか?
InnerClasses 属性はバイト コード内にあり、外部クラスの既知のすべての内部クラスを一覧表示します。これは、直接使用できるものではありません。
たとえば、内部/ネストされたクラスは $ でマングリングする名前に従う必要がありますか、それともこれは単なる慣例ですか?
コンパイラはこの規則に従いますが、それを制御することはできません。
内部クラス属性を設定せずにクラスを内部/ネストされたクラスのように JVM に見せる方法はありますか?これは JLM ベンダーに依存しますか? (IBM の実装では、一部の要件がそれほど厳密ではなかったと聞いたのを覚えています。)
同じ名前のクラスを作成できます。あなたはそれを自分で試してみることができます。
JVM のクラス ローディング メカニズムは、Java リフレクションとどの程度相互作用しますか?
クラスローダーがリフレクションを使用しているとは思いません。ただし、リフレクションは、クラス ローダーと同じ場所から情報を取得する場合があります。なぜそれが重要なのかわかりません。
JVM が Java リフレクションの結果と一致しないようにすることは可能でしょうか?
リフレクションを使用して、リフレクション ベースのオブジェクトのデータを破損できます。繰り返しますが、なぜこれをやりたいのかわかりません。