質問の歴史。
Javaは、レガシーコードとの後方バイナリ互換性を確保するために、バージョン5で型消去を使用してジェネリクスを導入しました。しかし、配列は再現されており、要素挿入時にArrayStoreExceptionチェックを強制するために、ランタイムでその要素タイプ（Class）を保持します。ジェネリック型パラメータであるTは、バイトコードでその上限（通常はObject）に消去されるため、JVMはランタイムでTを具体的なクラスに解決できず、コンパイル時型システムとランタイム配列検証の間に埋められないギャップを生じさせます。
問題。
もしコンパイラがnew T[10]を許可した場合、生成されたバイトコードはObject[]をインスタンス化しますが、参照変数はT[]であると主張します。この不一致により、ヒープ汚染が可能になります。String[]型の配列参照にIntegerが格納される可能性があり（実際にはObject[]を指しています）、JVMの型ガードをバイパスしてしまいます。この破損は、元の挿入ポイントから遠く離れた後の読み取り操作でClassCastExceptionを引き起こすまで潜在的に残り、Javaの静的型安全性の保証を侵害し、デバッグを非常に困難にします。
解決策。
開発者は、型安全な代替手段を選ぶために直接のインスタンス化を避ける必要があります。java.lang.reflect.Array.newInstance(Class<T>, int)メソッドを使用すると、正しいランタイムClassコンポーネントタイプの配列を作成できます。あるいは、明示的なキャストを使用して**Object[]を使用し（@SuppressWarnings("unchecked")で警告を抑制）、または好ましくは、ランタイム配列作成を必要としないジェネリック型システムを完全に受け入れるArrayList<T>**や他のコレクションに置き換えます。
問題の説明。
高性能の線形代数ライブラリを設計する中で、チームは、ボクシングオーバーヘッドなしにDouble、Complex、およびカスタム数値タイプをサポートするためにジェネリック**Matrix<T>を必要としました。内部ストレージは、キャッシュローカリティと生の速度のために二次元配列T[][]を必要としました。問題は、コンストラクタ内でコンパイラエラーを引き起こさずにT[][]**をインスタンス化することでした。
解決策1: Object[]配列の未チェックキャスト。
1つの提案では、(T[][]) new Object[rows][cols]とキャストし、アノテーションで未チェックの警告を抑制することが含まれていました。このアプローチはパフォーマンスオーバーヘッドがゼロで、メモリレイアウトの直接制御を可能にしました。しかし、これは脆弱な契約を生み出しました。もしMatrixが内部配列をゲッターを介して公開した場合、外部コードが不適合な型を挿入することでヒープを汚染でき、行列乗算中にClassCastExceptionの失敗が発生し、それを元の腐敗ポイントに追跡することはほぼ不可能になります。
解決策2: Objectストレージによる要素ごとのキャスト。
別のオプションは、データをObject[][]として格納し、読み取り操作ごとに個々の要素をTにキャストすることでした。これにより、取得サイトでの型不一致を即座に検出でき、デバッグが大幅に簡単になりました。欠点は、膨大なボイラープレートコードと、繰り返しのcheckcastバイトコード命令による計測可能な5-10%のパフォーマンスペナルティが発生し、ライブラリの主な目標であるネイティブ配列のパフォーマンスにみ合わない結果となりました。
**解決策3: **Array.newInstance()を介したリフレクション。
チームは最終的に、**Array.newInstance(componentType, rows, cols)を利用し、呼び出し元にClass<T>トークンを提供させました。これにより、正確なランタイムタイプの配列が生成され、ヒープ汚染を完全に防止しつつ、ネイティブ配列の生の速度を維持しました。行列作成時のリフレクティブインスタンス化の一度限りのコストは、行列操作のO(n³)**計算負荷に比べてごくわずかであり、解決策は安全でないキャストやアクセスごとのオーバーヘッドなしにコンパイル時型安全を提供しました。
結果。
ライブラリは、定量的金融アプリケーションにおいて3年間の重使用で報告されたArrayStoreExceptionやClassCastExceptionエラーが一切ない状態で出荷されました。リフレクティブアプローチにより、プリミティブラッパーと複雑なカスタムタイプの両方に対するシームレスなサポートが可能になり、厳格な型チェックが重要な金融計算における静かなデータ破損を防ぎました。性能ベンチマークは、1回限りのリフレクションオーバーヘッドが行列操作の計算コストに比べてごくわずかであることを確認しました。
なぜワイルドカード配列List<?>[]**は、パラメータ化された型の配列であるにもかかわらず、**List<String>[]**の型安全性の落とし穴を回避できるのか？** **List<?>[]**は不明なジェネリックリストの配列を表し、コンパイラはそれを生の型配列として扱います。このとき重要な制約は、非null要素を追加できないことです（なぜなら、型の互換性を検証できないからです）。List<String>[]は、すべての要素がList<String>であることが保証されている配列を意味しますが、消去後、JVMはそれをList[]のみとして認識します。もし許可されていれば、List<Integer>を配列の要素に割り当てることができ（ランタイムではListとしてしか存在しないため）、それをList<String>として取得し、要素にアクセスしたときにClassCastExceptionに遭遇する可能性があります。ワイルドカードバリアントは、書き込みを完全に許可しないことで、イミュータビリティ制約を通じて型安全性を保護します。
どうしてvarargsメソッド呼び出しは、呼び出し元でジェネリック配列をサイレントにインスタンス化するのか、また@SafeVarargsはなぜヒープ汚染リスクを解決するのではなくマスクするだけなのか？
void process(T... items)と宣言すると、コンパイラは引数を保持するためにT[]配列を合成しますが、それは消去後に実際にはObject[]になります。@SafeVarargsアノテーションはコンパイラの警告を抑制しますが、バイトコードを変更することはなく、メソッドは依然としてT[]としてふりをしたObject[]を受け取ります。この危険性は持続します：もしメソッドがitems配列をフィールドに格納したり、外部に逃がしたりすると、その配列には非T要素が含まれている可能性があり（呼び出し元からのヒープ汚染によって）、その後の読み取り時にClassCastExceptionがトリガーされます。本当の安全性は、itemsをArrayList<T>に防御的にコピーするか、メソッド内でArray.newInstanceを使用することが必要です。
ジェネリック配列を使用してArrays.copyOfやSystem.arraycopyを利用する場合、ソースとデスティネーションが型的に互換性があるように見えても、なぜClassCastExceptionが発生することがあるのか、そしてClass.getComponentType()がどのように解決策を提供するのか？
Arrays.copyOfは、元の配列のランタイムクラスを使用してArray.newInstanceを内部的に利用します。もしObject[]からの不正なキャストで作成されたT[]がある場合、そのコンポーネントタイプはObjectであり、Tではありません。**Arrays.copyOf(original, newLength)**でコピーする場合、T[]にキャストできないObject[]を受け取ることになり、すぐにClassCastExceptionがスローされます。解決策は、**Class<T>**トークンを別途追跡し、配列のクラスオブジェクトに頼るのではなく、**Array.newInstance(componentType, length)**を呼び出すことで、新しい配列が消去された実装ではなく、意図したジェネリック型に一致することを確認します。