モジュール java.base
パッケージ java.util

インタフェースCollection<E>

型パラメータ:
E - このコレクション内の要素の型
すべてのスーパー・インタフェース:
Iterable<E>
既知のすべてのサブインタフェース:
BeanContext, BeanContextServices, BlockingDeque<E>, BlockingQueue<E>, ClassPrinter.ListNodePREVIEW, Deque<E>, EventSet, List<E>, NavigableSet<E>, Queue<E>, SequencedCollection<E>, SequencedSet<E>, Set<E>, SortedSet<E>, TransferQueue<E>
既知のすべての実装クラス:
AbstractCollection, AbstractList, AbstractQueue, AbstractSequentialList, AbstractSet, ArrayBlockingQueue, ArrayDeque, ArrayList, AttributeList, BeanContextServicesSupport, BeanContextSupport, ConcurrentHashMap.KeySetView, ConcurrentLinkedDeque, ConcurrentLinkedQueue, ConcurrentSkipListSet, CopyOnWriteArrayList, CopyOnWriteArraySet, DelayQueue, EnumSet, HashSet, JobStateReasons, LinkedBlockingDeque, LinkedBlockingQueue, LinkedHashSet, LinkedList, LinkedTransferQueue, PriorityBlockingQueue, PriorityQueue, RoleList, RoleUnresolvedList, Stack, SynchronousQueue, TreeSet, Vector

public interface Collection<E> extends Iterable<E>
コレクション階層のルート・インタフェースです。 コレクションは、その要素であるオブジェクトのグループを表します。 コレクションによっては要素の重複を許可しますが、許可しないコレクションもあります。 オーダーされたものもあれば、オーダーされなかったものもあります。 「見つける」が定義されているコレクションは、通常、SequencedCollectionインタフェースのサブタイプです。 JDKでは、このインタフェースのdirect実装は提供されません: SetListなど、より具体的なサブインタフェースの実装を提供します。 このインタフェースは、通常は、最大限の普遍性が求められる場面でコレクションを渡したり、そのコレクションを操作するために使用されます。

Bagまたはマルチセット (重複要素を格納できる、順序付けのないコレクション)は、このインタフェースを直接実装する必要があります。

すべての汎用Collection実装クラス(通常、サブインタフェースの1つを介してCollectionを間接的に実装)は、2つの"standard"コンストラクタを提供する必要があります: 空のコレクションを作成するvoid (引数なし)コンストラクタと、引数と同じ要素を持つ新しいコレクションを作成するCollection型の単一の引数を持つコンストラクタ。 したがって、後者のコンストラクタでは、ユーザーはどのコレクションでもコピーでき、希望の実装型のコレクションと完全に同じコレクションを生成できます。 この規則(インタフェースにコンストラクタを含めることができないため)を強制する方法はありませんが、Javaプラットフォーム・ライブラリのすべての汎用Collection実装が準拠しています。

特定のメソッドは、optionalとして指定されます。 コレクション実装が特定の操作を実装しない場合、対応するメソッドを定義してUnsupportedOperationExceptionをスローする必要があります。 このようなメソッドは、コレクション・インタフェースのメソッド仕様に"オプションの操作"とマークされています。

いくつかのコレクション実装には、要素に含まれる可能性のある制限があります。 たとえば、null要素を禁止する実装や、null要素の型に制限がある実装もあります。 不適格要素を追加しようとすると、チェックされていない例外(通常はNullPointerExceptionまたはClassCastException)がスローされます。 不適格な要素を照会しようとすると、例外がスローされる場合や、ただfalseを返す場合もあります。前者の動作を実行する実装もあれば、後者の動作を実行する実装もあります。 ほとんどの場合、処理が完了しても不適格な要素のコレクションへの挿入が発生しないような不適格な要素の処理を試みると、実装のオプションに応じて例外がスローされるか、または正常に終了します。 このインタフェースの仕様では、そうした例外は「任意」と記載されています。

独自の同期ポリシーを決定するかどうかは、それぞれのコレクションによって異なります。 実装による強い保証がない場合、別のスレッドによって変更されるコレクションでメソッドを呼び出すと、定義されていない動作が発生する可能性があります。これには、直接の呼び出し、呼出しを実行する可能性があるメソッドへのコレクションの引渡し、および既存のイテレータを使用したコレクションの検査が含まれます。

Collections Frameworkインタフェース内の多数のメソッドは、equalsメソッドとの関連で定義されます。 たとえば、contains(Object o)メソッドの指定では次のようになります : "このコレクションに(o==null ? e==null : o.equals(e))のような要素eが少なくとも1つ含まれている場合のみ、trueを返します。" この指定は、null以外の引数oを指定してCollection.containsを呼び出すと、要素eに対してo.equals(e)が呼び出されることを意味するように解釈しないでください。 実装は、2つの要素のハッシュ・コードを最初に比較するなどして、equalsの呼出しを回避する最適化を自由に実装できます。 (Object.hashCode()仕様では、等価ではないハッシュ・コードを保持する2つのオブジェクトは等価ではないことが保証されます。) もう少し一般的に言うと、さまざまなCollections Frameworkインタフェースの実装で、実装者が適切と判断するなら、基本となるObjectメソッドの指定された動作を自由に利用できます。

コレクションの再帰的なトラバーサルを行うコレクション操作の中には、コレクションにそれ自身が直接または間接的に含まれる自己参照型インスタンスの例外によって失敗するものがあります。 これには、clone()equals()hashCode()、およびtoString()メソッドが含まれます。 実装ではオプションで自己参照シナリオを処理できますが、最新の実装では行われていません。

コレクションを表示

ほとんどのコレクションでは、格納されている要素のストレージが管理されます。 対照的に、「コレクションを表示」自体は要素を格納しませんが、実際の要素を格納するためにバッキング・コレクションに依存します。 ビュー・コレクション自体で処理されない操作は、バッキング・コレクションに委任されます。 ビュー・コレクションの例には、Collections.checkedCollectionCollections.synchronizedCollectionCollections.unmodifiableCollectionなどのメソッドによって返されるラッパー・コレクションがあります。 ビュー・コレクションのその他の例には、List.subListNavigableSet.subSetMap.entrySetSequencedCollection.reversedなど、同じ要素の異なる表現を提供するコレクションがあります。 バッキング・コレクションに加えられたすべての変更は、ビュー・コレクションに表示されます。 これに対応して、ビュー・コレクションに加えられた変更 - 変更が許可されている場合 - バッキング・コレクションに書き込まれます。 これらは技術的にはコレクションではありませんが、IteratorおよびListIteratorのインスタンスでは、バッキング・コレクションへの変更の書込みも許可され、場合によっては反復中にバッキング・コレクションへの変更が表示されることがあります。

変更不可能なコレクション

このインタフェースの特定のメソッドは"destructive"とみなされ、"mutator"メソッドと呼ばれ、操作対象のコレクション内に含まれるオブジェクトのグループを変更します。 このコレクションの実装が操作をサポートしていない場合、UnsupportedOperationExceptionをスローするように指定することができます。 そのようなメソッドは、呼び出しがコレクションに影響を与えない場合、UnsupportedOperationExceptionをスローする必要があります。 たとえば、add操作をサポートしていないコレクションを考えてみましょう。 addAllメソッドがこのコレクションで呼び出され、引数として空のコレクションがある場合はどうなりますか? ゼロ要素の追加は効果がないため、このコレクションでは何もしないで例外をスローすることはできません。 ただし、このような場合は、例外をスローすると無条件に例外がスローされることが推奨されます。

「変更不可能なコレクション」はコレクションであり、すべてのメソッド(上で定義したように)がUnsupportedOperationExceptionをスローするように指定されています。 したがって、そのようなコレクションは、その上の任意のメソッドを呼び出すことによって変更することはできません。 コレクションを適切に変更できないようにするには、コレクションから派生したビュー・コレクションも変更不可能でなければなりません。 たとえば、Listを変更できない場合、List.subListによって返されたListも変更不可能です。

変更不可能なコレクションは必ずしも変更できません。 含まれている要素が変更可能な場合、コレクション全体が変更不可能であっても、明らかに変更可能です。 たとえば、変更可能な要素を含む2つの変更不可能なリストを考えてみましょう。 両方のリストが変更不可能であっても、要素が変更された場合、list1.equals(list2)を呼び出した結果は、呼び出しごとに異なる場合があります。 ただし、変更不能なコレクションにすべての変更不能な要素が含まれている場合は、効果的に不変であると見なすことができます。

変更不可能なビュー・コレクション

「変更不可能なビュー・コレクション」は変更不可能なコレクションで、バッキング・コレクションのビューです。 そのメソッドは上記のようにUnsupportedOperationExceptionをスローしますが、読み込みメソッドと問合せメソッドはバッキング・コレクションに委譲されます。 その効果は、バッキング・コレクションへの読み取り専用アクセスを提供することです。 これは、内部コレクションへの読み取りアクセスをユーザーに提供し、そのコレクションが予期せず変更されるのを防ぐために役立ちます。 変更不可能なビュー・コレクションの例として、Collections.unmodifiableCollectionCollections.unmodifiableListおよび関連するメソッドによって返されるものがあります。

バッキング・コレクションへの変更は引き続き可能であり、変更が発生した場合は変更不可能なビューで表示されることに注意してください。 したがって、変更不可能なビュー・コレクションは必ずしも不変であるとは限りません。 ただし、変更不可能なビューのバッキング・コレクションが効果的に不変である場合、またはバッキング・コレクションへの参照が変更不可能なビューのみである場合、ビューは効果的に不変であるとみなすことができます。

コレクションの直列化可能性

コレクションの直列化可能性はオプションです。 このため、どのコレクション・インタフェースもSerializableインタフェースを実装するように宣言されていません。 ただし、直列化可能性は一般に有用と考えられるため、ほとんどの収集実装は直列化可能です。

(ArrayListまたはHashMapなどの)のパブリック・クラスであるコレクション実装は、実際に直列化可能なSerializableインタフェースを実装するように宣言されています。 一部のコレクション実装は、「変更不可能なコレクション」などのパブリック・クラスではありません。 このような場合、このようなコレクションの直列化可能性については、そのコレクションを作成するメソッドの指定またはその他の適切な場所で説明されています。 コレクションの直列化可能性が指定されていない場合、このような収集の直列化可能性に関する保証はありません。 特に、元のコレクションが直列化可能であっても、多くの「コレクションを表示」は直列化可能ではありません。

Serializableインタフェースを実装するコレクション実装は、直列化可能であることを保証できません。 その理由は、コレクションには他の型の要素が含まれているため、一部の要素型のインスタンスが実際に直列化可能かどうかを静的に判断できないためです。 たとえば、ESerializableインタフェースを実装していない直列化可能なCollection<E>について考えてみます。 コレクションは、Eの直列化可能なサブタイプの要素のみが含まれている場合、または空の場合は、直列化可能です。 このため、コレクションは、コレクション全体の直列化可能性として「条件付きで直列化可能」と言われています。これは、コレクション自体が直列化可能かどうか、および含まれるすべての要素も直列化可能かどうかによって異なります。

SortedSetおよびSortedMapのインスタンスでは追加のケースが発生します。 これらのコレクションは、セット要素またはマップ・キーに順序付けを行うComparatorを使用して作成できます。 そのようなコレクションは、Comparatorが直列化可能である場合にのみ直列化可能です。

このインタフェースは、Java Collections Frameworkのメンバーです。

実装要件:
デフォルトのメソッド実装(継承または別の方法によるもの)は、同期プロトコルを適用しません。 Collectionの実装に特定の同期プロトコルが含まれている場合は、デフォルトの実装をオーバーライドしてそのプロトコルを適用する必要があります。
導入されたバージョン:
1.2
関連項目: