Collections Framework の主な利点は、次のとおりです。
Collections Framework は、次の要素で構成されます。
コレクションインタフェースは 2 つのグループにわかれます。もっとも基本的なインタフェースは java.util.Collection で、次の子孫があります。
そのほかのコレクションインタフェースは、java.util.Map に基づいていて、真の意味でのコレクションではありません。ただし、これらのインタフェースには collection-view オペレーションが含まれているため、コレクションとして操作することが可能です。Map には、次の子孫があります。
コレクションインタフェースの変更メソッドの多くには、オプションというラベルが付いています。実装では、いくつかのオペレーションの実行が許可されません。実行しようとすると、実行時例外 (UnsupportedOperationException) がスローされます。各実装のドキュメントでは、サポートされるオプションのオペレーションを指定する必要があります。この仕様を理解するための助けとして、いくつかの用語が導入されています。
実装によっては、格納する要素 (Maps の場合はキーおよび値) を限定する場合があります。要素を限定する条件には、次のようなものがあります。
実装の制限に適合しない要素を追加しようとすると、実行時例外が発生します。典型的な実行時例外には、ClassCastException、IllegalArgumentException、また NullPointerException があります。実装の制限に適合しない要素を削除またはテストしようとすると、例外が発生することがあります。制限付きのコレクションによっては、その使用法を許可していることがあります。
一般に、コレクションインタフェースを実装するクラスは、<Implementation-style><Interface> という形式の名前を持ちます。次の表に、汎用の実装の概要を示します。
インタフェース | ハッシュテーブル | サイズ変更可能な配列 | バランスツリー | リンクリスト | ハッシュテーブル + リンクリスト |
---|---|---|---|---|---|
Set |
HashSet | TreeSet | LinkedHashSet | ||
List |
ArrayList | LinkedList | |||
Deque |
ArrayDeque | LinkedList | |||
Map |
HashMap | TreeMap | LinkedHashMap |
汎用の実装は、コレクションインタフェースのオプションのオペレーションをすべてサポートしています。また、格納する要素に制限はありません。これらの実装は非同期ですが、Collections クラスには、同期ラッパーと呼ばれる static ファクトリが含まれます。同期ラッパーは、同期をとらない多くのコレクションに同期をとる機能を追加するために使用されます。新規の実装にはすべて、フェイルファストイテレータが含まれます。フェイルファストイテレータは、無効な並列変更を探知し、すばやくクリーンにフェイルします。不規則な動作はしません。
AbstractCollection、AbstractSet、AbstractList、AbstractSequentialList、および AbstractMap クラスは、コアコレクションインタフェースの基本的な実装を提供し、実装に必要な手間を最小限に抑えます。これらのクラスの API ドキュメントには、各メソッドがどのように実装されているかが説明されているため、実装者は、特定の実装の「基本オペレーション」のパフォーマンスに基づき、どのメソッドをオーバーライドしたらよいかがわかります。
複数のスレッドからのコレクションを使用するアプリケーションは、慎重にプログラミングする必要があります。一般に、これは並行プログラミングと呼ばれます。Java プラットフォームは、並行プログラミングを幅広くサポートします。詳細については、「Java 並行処理ユーティリティー」を参照してください。
コレクションは使用頻度が高いため、コレクションの並行処理に適した各種のインタフェースおよび実装が API に含まれています。これらのタイプは、前述の同期ラッパーを超えて、並行プログラミングで頻繁に必要とされる機能を提供します。
並行処理に対応するこれらのインタフェースを使用できます。
並列処理に対応する次の実装クラスを使用できます。これらの実装の適切な使用法については、API ドキュメントを参照してください。
設計上の主要な目標は、実際のサイズにおいて、またより重要性の高い「概念の重さ」においても小さい API を作成することでした。現在の Java プログラマにとって、この新機能が大きく違うものには見えないようにするということも非常に重要な点でした。このため、既存の機能を置き換えるのではなく、機能を追加する必要がありました。同時に、この新しい API は、上記の利点すべてを提供できるような強力なものにする必要がありました。
コアインタフェースを小さく保つために、インタフェースはこのようなわずかな違いを可変、修正、サイズ変更としてはとらえません。コアインタフェースでのある種の呼び出しはオプションであり、実装は、特定の省略可能なオペレーションに関しては UnsupportedOperationException をスローして、サポートしないことを示せるようにしました。コレクションの実装者は、実装がオプションのオペレーションのうち、どれをサポートしているかをドキュメントに明示する必要があります。
各コアインタフェース内のメソッドの数を少数に保つために、メソッドが次のどれかの場合にだけ、インタフェースはメソッドを格納します。
コレクションの妥当な表現が、すべて相互運用可能であることは重要な要件です。この表現には配列が含まれます。配列は、言語を変えずに直接 Collection インタフェースを実装することはできません。このため、フレームワークには、コレクションを配列に移動できるメソッド、コレクションとみなすことのできる配列、およびコレクションとみなすことのできるマップが含まれています。