【ITニュース解説】Generics and Variance with Java

Javaプログラミングでは、データを扱う際に「型」という概念が非常に重要である。この解説では、Javaの「ジェネリクス」と「バリアンス」という、より柔軟で安全なコードを書くための仕組みについて、システムエンジニアを目指す初心者にも理解できるように説明する。

まず、「型」と「サブタイプ」の関係から見ていこう。Javaでは、あるクラスが別のクラスを継承している場合、継承元のクラス（基底型）の変数に、継承先のクラス（サブタイプ）の値を代入できる。これは「ワイドニング参照代入」と呼ばれ、例えばFloat型はNumber型のサブタイプなので、Floatの値をNumber型の変数に代入できる。

Copy
1Float myFloat = Float.valueOf(3.14f);
2Number number = myFloat; // 問題なく代入できる

次に、「バリアンス」という概念について考える。これは、元の型（例えばFloatとNumber）のサブタイプ関係が、別の型（例えば配列）の文脈でどのように影響するかを示すものだ。Javaの配列は「共変（covariant）」である。これは、FloatがNumberのサブタイプであれば、Floatの配列（Float[]）もNumberの配列（Number[]）のサブタイプとして扱えるという意味である。

Copy
1Float[] floats = new Float[10];
2Number[] numbers = floats; // コンパイルが通る

この共変性は、サブタイプ関係が基底型と同じ方向に保たれることを示す。しかし、配列の共変性には潜在的な問題がある。上記の例で、numbers[0] = integer;のように、実際にはFloat型の配列であるfloatsにInteger型の値を代入しようとすると、コンパイルは通ってしまう。Javaの配列は「再具象化（reified）」されているため、実行時にはその型情報が保持されており、このような不適切な代入が起こるとArrayStoreExceptionという実行時エラーが発生してプログラムが停止する。これは問題のあるコードが早期に検出されるという点では良いが、コンパイル時には見つけられない欠陥である。

この配列の型安全性の問題を解決し、より柔軟な型表現を可能にするために、Java 5で「ジェネリクス」が導入された。ジェネリクスが導入される前は、Listのようなコレクションに異なる型のオブジェクトが混在する可能性があり、要素を取り出す際には手動で型キャストを行う必要があった。このキャストが誤っていると、実行時にClassCastExceptionが発生した。

Copy
1List strings = new ArrayList(); // ジェネリクスなし
2strings.add(3); // コンパイルが通る
3String string = (String) strings.get(0); // 実行時エラーが発生

ジェネリクスを使うと、コレクションの型を宣言時に指定することで、型安全性を確保できる。

Copy
1List<String> strings = new ArrayList<>(); // ジェネリクスを使用
2strings.add(3); // コンパイルエラーになる
3strings.add("hello world"); // コンパイルが通る
4String string = strings.get(0); // 明示的なキャスト不要で型安全

ジェネリクスでは、クラスやメソッドに一つ以上の「型パラメータ」を設定できる。例えば、Pair<K, V>というクラスは、キーKと値Vという任意の2つの型を持つオブジェクトの組（タプル）を作成できる。また、型パラメータに制約を設けることも可能で、T extends Entity & Serializable & Comparable<T>のように、Tが特定のインターフェースを実装していることや、特定のクラスを継承していることを強制できる。これは、例えばリポジトリクラスで永続化可能なエンティティ型だけを扱いたい場合などに便利である。型パラメータが自分自身を引数に取るような「再帰的な型境界」という特殊なケースもある。これはComparableインターフェースの設計などで見られる。

メソッドにも型パラメータを適用できる。例えば、firstElement(List<T> items)のように、リストの最初の要素を型安全に取り出すメソッドを定義できる。

重要なのは、配列と異なり、ジェネリクスは基本的に「不変（invariant）」であるという点だ。つまり、IntegerはNumberのサブタイプだが、List<Integer>はList<Number>のサブタイプではない。

Copy
1List<Number> numbers = new ArrayList<Integer>(); // コンパイルエラーになる

もしこれが許されると、List<Integer>にFloatのような異なる型のオブジェクトが誤って追加されてしまう可能性がある。配列の場合、実行時にArrayStoreExceptionでエラーになるが、ジェネリクスの場合はそうはいかない。なぜなら、Javaのジェネリクスは「型消去（Type Erasure）」という仕組みを採用しているため、コンパイル後に型パラメータの情報（例:<String>や<Integer>)がほとんど失われ、実行時にはList<Object>のように振る舞うからだ。そのため、instanceof List<String>のようなチェックもできない。ジェネリクスが型情報を実行時に持たない（「非再具象化」である）ため、誤った型のオブジェクトがコレクションに挿入されたとしても、実行時にはすぐにエラーにならず、後々そのオブジェクトを使用しようとしたときに初めて問題が発生する可能性がある。このような状況を「ヒープ汚染（Heap Pollution）」と呼ぶ。ジェネリクスは、コンパイル時に型チェックを厳密に行うことで、このようなヒープ汚染を未然に防ぎ、コードの型安全性を高めている。

しかし、この不変性だけでは、せっかくのサブタイプ関係を活かせない場面が出てくる。そこで登場するのが、ジェネリクスにおける「ワイルドカード」を使った「バリアンス」だ。バリアンスは「共変性」と「反変性」の二つに分けられ、「PECS（Producer Extends, Consumer Super）」という覚え方が有名である。

「共変性（? extends T）」は、型パラメータTのサブタイプを許可するワイルドカードだ。例えば、List<? extends Number> numbersという変数には、List<Float>やList<Integer>を代入できる。これは、このリストから要素を取り出す際には、少なくともNumber型として安全に扱えるため、「生産者（Producer）」として機能する。例えば、MyStack<T>クラスにpushAll(List<? extends T> items)メソッドを追加すると、MyStack<Number>にList<Integer>の要素をまとめてpushできるようになる。しかし、List<? extends Number>に対してnumbers.add(0)のように要素を追加しようとすると、コンパイルエラーになる。これは、実際にどんな型のリスト（List<Integer>かList<Float>かなど）が渡されたか不明なため、誤った型の追加を防ぐための安全策だ。

一方、「反変性（? super T）」は、型パラメータTのスーパタイプ（基底型）を許可するワイルドカードだ。例えば、List<? super Integer> itemsという変数には、List<Number>やList<Object>を代入できる。これは、このリストに要素を追加する際には、少なくともInteger型またはそのサブタイプを安全に追加できるため、「消費者（Consumer）」として機能する。例えば、MyStack<Integer>から要素をポップしてpopAll(List<? super Integer> items)メソッドを使ってList<Object>に格納する、といったことが可能になる。しかし、List<? super Integer>から要素を取り出す際には、その型がObjectとしてしか扱えないという制限がある。

ワイルドカードには、型を一切指定しない「非境界ワイルドカード（<?>）」もある。これは、List<?> arbitraryList = new ArrayList<Integer>();のように記述し、リストの要素型に関心がない場合に使用する。この場合、要素の追加はnullのみ可能であり、取り出した要素はObject型として扱われる。Collection.containsAll(Collection<?> c)のように、特定の型の要素を操作せず、コレクションの汎用的な操作を行う場合に有用である。

これらを組み合わせることで、より柔軟なコードが書けるようになる。例えば、copy(List<? super T> destination, List<? extends T> source)メソッドは、sourceリスト（生産者）からT型またはそのサブタイプの要素を取り出し、destinationリスト（消費者）にT型またはそのスーパタイプの要素として追加する。これにより、List<Integer>をList<Number>にコピーするような、型が異なるリスト間のコピーが型安全に行えるようになる。

また、ワイルドカードを使用する際に発生する「型キャプチャ」という現象がある。例えば、List<?>に対して要素の交換を行うswapメソッドを書くと、list.set(i, list.set(j, list.get(i)))のような操作はコンパイルエラーになる。これは、ワイルドカードが表す具体的な型が不明なためだ。この問題は、内部的にジェネリック型パラメータを持つヘルパーメソッドを呼び出すことで解決できる。これにより、コンパイラがワイルドカードの背後にある具体的な型を「キャプチャ」し、型安全な操作を可能にする。

最後に、メソッドのパラメータとしてワイルドカードを使用することは柔軟性を高めるため良い設計とされているが、メソッドの戻り値の型にワイルドカードを使用することは、クライアント側のコードを複雑にするため、一般的には推奨されない。バリアンスは、型安全性を維持しつつAPIに柔軟性をもたらすための強力なツールであり、適切に理解して活用することで、より堅牢で保守しやすいJavaアプリケーションを開発できる。