Java ジェネリックスの「super」キーワードがワイルドカードに制限されており、型パラメーターには制限されていないのはなぜですか?

「super」キーワードによるジェネリックの境界

なぜ super キーワードは Java ジェネリックの型パラメータではなくワイルドカードにのみ適用されるのか不思議に思う人もいるかもしれません。 Collection インターフェイスの次の例を考えてみましょう。ここでは、toArray メソッドが次のように宣言されていません:

interface Collection<T> {
    <S super T> S[] toArray(S[] a);
}

この構文は不正な宣言につながります。その理由を理解するには、named で super を使用することの影響を調べる必要があります。型パラメータ。

型パラメータの 'super' の制限

名前付き型パラメータ () を制限するために super を使用しても、意図した効果。 Object はすべての参照型の最終的なスーパークラスであるため、参照型の配列は Object[] にキャストできます。これは、仮定の構文を使用しても、次のコードはコンパイルされ、実行時に ArrayStoreException が発生することを意味します:

List<Integer> integerList;
integerList.toArray(new String[0]);  // should be disallowed, but compiles

したがって、名前付き型パラメータでは super を使用できません。

ジェネリックと配列: 複雑な関係

考慮すべきもう 1 つの側面は、ジェネリックと配列の間の複雑な相互作用です。 Java では、配列は他のコレクション型とは異なる方法で扱われるため、型安全性の強制に制限が生じます。これは、指定された例でジェネリック型の境界が ArrayStoreException を防ぐことができない理由を説明しています。

'super' を使用した不正な境界の例

この問題をさらに詳しく説明するために、仮説的な方法を考えてみましょう。宣言:

<T super Integer> void add(T number)  // hypothetical! currently illegal

この構文では、Integer インスタンスと Number インスタンスは受け入れられるが、String インスタンスは受け入れられないと思われるかもしれません。ただし、String は Object のサブクラスであり、Object は Integer のスーパークラスであるため、add(aString) がコンパイルされる可能性があり、潜在的なエラーが発生します。

結論

結論として、型の安全性を確保し、無効な仮定を防ぐために、名前付き型パラメーターでの super の使用は制限されています。 Java のジェネリックと配列には、スーパーを使用して型パラメーターを境界付ける効果を制限する独自の特性があります。

以上がJava ジェネリックスの「super」キーワードがワイルドカードに制限されており、型パラメーターには制限されていないのはなぜですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。