OpenJDKの上の投稿で JEP 186 Oracle’s Brian Goetz informs that Oracle will not be pursuing collection literals as a language feature in JDK8.
A リテラルコレクション 配列として集合型に評価される構文上の表現形式であります, リストまたは地図. プロジェクトコイン 提案されたコレクションリテラル, また、Java SE8のライブラリの追加を補完します. 仮定は、コレクションリテラルは生産性を向上させるというものでした, コードの可読性, そして、コードの安全性.
別の方法として、Oracleが示唆 ライブラリベース インターフェイス上の静的メソッドの概念に基づいて提案. 実装は、理想的には新しい専用不変クラス経由になります.
このライブラリベースのアプローチの背後にある主要なポイントは次のとおり.
- この機能の基本的な解決策は、セットでのみ動作します, リストとマップのように、それは非常に満足のいくか人気がありません. 他のコレクション型の拡張可能なセットをカバーするための高度なソリューションは、オープンエンドであります, 乱雑な, 事実上その設計予算をオーバーランウェイに保証.
- ライブラリベースの変更がための要件の多くを除去することになります “コレクションリテラル” プロジェクトコインで議論変更.
- ライブラリベースのアプローチは、のため利益のx％を与えます 1% コストの, ここで、X >> 1.
- 値の型は、今後、この新しい機能の動作しています (コレクションリテラル) 値型と知られていません. これは、値型の前にリテラルのコレクションをしようとしない方が良いです.
- これは、ライブラリベースのバージョンの基礎となる基礎的な問題に対処する上で、Oracleの言語設計帯域幅を中心にしたほうが良いです. これは、より効率的な可変引数を含み, 定数プール内の配列定数, 不変の配列, キャッシュのサポート (加圧下で再利用) 中間不変結果.
Oracleのブライアン・ゲッツによると、, 本当の痛みは、マップではないリストであります, 設定または配列. ライブラリベースのソリューションは、リストのより許容されます, セットと配列. しかし、このアプローチは、まだマップなどペアリテラルを記述するための合理的な方法を欠いています. インタフェースのstaticメソッドは、ライブラリベースのソリューションは、より実用的なもの. 値の種類はあまりにもはるかに実用的な地図のためのライブラリベースのソリューションを作ります. ザ・ proof of concept ライブラリベースのソリューション用のパッチも入手可能です.
