Collectionsだ。いったAPIが追加される。3);設計と実装の課題としては以下のものがあった。EfficiencySerializability新しいstaticファクトリメソッドが返すコレクションはイミュータブルとなる。これは従来の不変性であり、不変の永続性ではない(addなどはUnsupportedOperationExceptionをスローする)。不変性はよいものである。一般的な場合、コレクションは既知の値で初期化した後、変更することはない。不変であれば自動的にスレッドセーフになる。効率、とくにスペースについて改善するチャンスがある。JDKには一般的な目的のための不変コレクションはない。Setの要素とMapのキーのイテレーションの順序については、HashSetやHashMapであれば公式には順序が保証されないとしていたが、長い間たいてい一貫していた。これを変更すると、順序に依存しているコードは動作が変わってしまう。適用するのは新しいコレクション実装だけにする。既存のコレクションは同じままとなるだろう。ListやSetの要素、Mapのキーや値にnullを許可しない。NullPointerExceptionをスローする。1.2でコレクションにnullを許可したのは失敗だった。5以降コレクションではnullを許可していない。java.util.concurrentのコレクションではそうだ。nullはNullPointerExceptionの原因だからだ。Setの要素やMapのキーで重複したときはIllegalArgumentExceptionをスローする。”コレクションのリテラル”で重複があるのはプログラミングのエラーである可能性が高い。理想的にはこれをコンパイル時に検出する。値はコンパイル時の定数ではない。次にいいのは、実行時の生成においてフェイルファストにする。2つの文字列の要素を持つSetを考えてみる。Collections.unmodifiableSet(set);どのぐらいスペースを使っているのか?オブジェクトを数えてみる。unmodifiableなラッパーが1つHashSetが1つHashMapが1つ長さが3のObject配列のテーブルが1つNodeオブジェクトが2つ、各要素に1つずつサイズの見積もりとしては、オブジェクトごとに12バイトのヘッダーがある(64ビットJVMで32GB未満のヒープ、OOP圧縮あり)。int、float、参照フィールドごとにプラス4バイトだ。いうことは、先ほどのオブジェクトを合計すると152バイトになる。56バイトフィールドベースのSet実装だとオブジェクト1つとフィールド2つで20バイトとなる。"bar");実装はすべてstaticファクトリの背後にあるプライベートなクラスとしている。コレクションはすべてシリアライズできる。デフォルトのシリアライズ形式は内部実装について漏らしてしまっていた。新しいコレクションの実装は、カスタマイズしたシリアライズ形式となる。将来的な作業これらはまだ計画されていない将来的な作業だ。VectorやHashtableといったレガシーなコレクションは非推奨にする。LinkedListもそうするかもしれない。コアなコレクションのイテレーション順序をランダムにする。新しいミューテータのデフォルトメソッドを追加する。ArrayDequeへのインデックスアクセスを追加する。269のコレクション拡張では、パフォーマンスの改善と、順序があるSet/Mapを追加する。感想Stuartさんのセッションは熱い感じで印象深かったです。これはStuartさんの最後のセッションでしたが、他2つ、Stuartさんのすべてのセッションを聴きました。このセッションの内容としては、Javaプログラミングで使わないことはほぼないであろう、コレクションについて歴史をたどれ、興味深いものでした。269については、以前私は個人ブログにて動作確認していました。そのためAPIの追加は知っていました。ほかにも数多くの改善があり、とくにコレクションが使うスペースについて理解が深まったのはうれしいです。