ダイヤモンド演算子（<>）はJava 7で導入され、当初は具体的なクラスインスタンス作成式のみに対応し、匿名内部クラスを明示的に除外していました。開発者がnew Comparable<String>() { ... }のような構築を試みた場合、コンパイラはダイヤモンドバリアントnew Comparable<>() { ... }を拒否しました。というのも、匿名クラスは推論された型パラメータを参照する型メンバーを導入する可能性があり、これは健全でない型システムを作成する可能性があったからです。
核心的な問題は非指定型に関するものでした。匿名クラスは、その型がクラスの型パラメータに依存するメソッドやフィールドを宣言することができます。もしコンパイラがダイヤモンドの複雑な交差型を推論した場合、具体的なシナリオでは、匿名クラスがvoid foo(Box<T> t) {}を宣言した場合、型Tはソースコードで表現できないキャプチャされたワイルドカードを表す可能性があります。これにより、匿名クラスのAPIに命名またはチェックできない型が含まれている状況が生じ、Javaの公的APIにおけるすべての型が指定可能でなければならないという基本的要件を侵害されることになります。
Java 9では、JEP 213を通じて指定可能型分析を実装することにより、これが解決されました。コンパイラは、匿名クラスのインスタンス化に対して推論された型が指定可能（すなわちJava型構文を用いて表現可能）であることを確認します。以下の例は合法的な使用法を示しています：
// Java 9+では有効 Comparator<String> c = new Comparator<>() { @Override public int compare(String a, String b) { return a.length() - b.length(); } };
もし推論が指定できないウィルドカードや交差を含む複雑な型を生じた場合、コンパイラは明示的な型引数を要求することに戻ります。これにより、一般的なケースのための簡潔な構文が許可される一方で、型安全性が確保されます。
Java 8を基に構築された金融取引プラットフォームでは、開発チームが数千のイベントハンドラを維持していました。これらのハンドラは、注文マッチングエンジン全体で**Comparator<TradeEvent>やPredicate<MarketData>**の匿名実装を使用しており、明示的な型引数が必要であり、その結果コードレビュー中に視覚的なノイズがかなり大きくなっていました。
チームはボイラープレートを削減するための3つのアプローチを検討しました。最初のアプローチはすべての匿名クラスをラムダ式に移行することでした。これにより単純なケースに対して冗長性が排除されましたが、多くのハンドラにはラムダの機能を超えるプライベートヘルパーメソッドや例外処理ブロックが必要でした。この制限のために、名付けられた内部クラスへの不自然なリファクタリングが強いられ、クラスの数が増え、動作の局所性が低下しました。
2番目のアプローチは明示的な型引数を維持することを提案しました。これにより完全な機能性が保たれ、既存のJava 8インフラストラクチャと互換性がありましたが、メンテナンスの負担が続きました。開発者は型シグネチャを変更する際に頻繁にマージ競合に直面し、冗長な宣言がデバッグセッション中の認知負荷を増加させました。
3番目のアプローチは、匿名クラスに対するダイヤモンド演算子サポートを利用するためにJava 9にアップグレードすることを提案しました。移行コストと生産性の向上を評価した結果、プラットフォームはJigsawモジュールシステムの統合が必要だったため、チームはJava 9アップグレードを選択しました。指定可能型分析により、new Comparator<>() { public int compare(TradeEvent a, TradeEvent b) { ... } }を記述できるようになり、コンパイラがTradeEventが指定可能型であることを検証しました。
この変化により、平均的なハンドラ定義が4行から1行に減少し、約2,400行の冗長な型宣言が排除されました。その結果、特にジェネリックが多いモジュールにおけるマージ競合が著しく減少し、フィーチャーブランチ間で明示的な型引数を同期する必要がなくなりました。開発の速度は、リファクタリングの負担が軽減されたことで、次の四半期に15%向上しました。
なぜダイヤモンド演算子は生の型におけるジェネリックコンストラクタの型引数を推論することに失敗するのか？
生のクラスをインスタンス化する場合（例：new ArrayList()<>）ダイヤモンド演算子は型引数を推論できません。これは生の型がジェネリック情報を完全に消去するためです。コンパイラは生の型を型パラメータがないものとして扱い、推論が不可能になります。候補者はこれをチェックされていない変換警告と混同することが多いですが、根本的な問題は生の型の文脈におけるジェネリックメタデータの完全な消去に関係しています。
多様式とダイヤモンド演算子の相互作用がメソッドオーバーロード解決に与える影響は？
ダイヤモンド演算子は、割り当てコンテキストに依存する多様式を生成します。process(new ArrayList<>())のようなメソッド呼び出しコンテキストでは、コンパイラは型推論を完了する前にメソッドの形式的なパラメータからターゲット型を決定する必要があります。これにより双方向の依存関係が生じます：メソッドの適用可能性は推論された型に依存しますが、推論された型はターゲット型に依存します。コンパイラはこの解決を制約生成および組み込みフェーズを通じて行い、明示的な型引数とは異なるオーバーロードを選択する可能性があります。候補者はオーバーロード解決が完全な型推論の前に発生することを見落としがちで、複数のオーバーロードが一致する可能性がある場合に予期しないコンパイル時エラーが発生することがあります。
指定可能型制限と配列作成における再確実型の要件を区別する点は？
両方の制限が特定のジェネリック操作を防ぐ一方で、指定可能型（ダイヤモンド演算子推論に関連）は型がソースコードで表現可能であることを保証するのに対し、再確実型（new T[10]に関連）はランタイム型情報を要求します。List<String>のような型は指定可能ですが再確実ではありません。候補者はしばしばこれらの制約を混同し、非指定可能型が配列ストア例外のようなランタイム安全リスクを引き起こすと誤解します。実際には、非指定可能型はソースレベルの型の表現可能性とAPIの一貫性を損なうのに対し、非再確実型はランタイム型安全性を損ないます。この区別を理解することは、匿名クラスや配列ベースのレガシーコードと互換性を保つ必要があるジェネリックAPIを設計する際に重要です。