Why does List interface extend Collection interface?

Question

The Collection interface has multiple methods. The List interface extends the Collection interface. It declares the same methods as the Collection interface? Why is this so?

For example

interface Collection extends Iterable
{
     public abstract int size();
 public abstract boolean isEmpty();
 public abstract boolean contains(java.lang.Object);
 public abstract java.util.Iterator<E> iterator();
 public abstract java.lang.Object[] toArray();
 public abstract <T extends java/lang/Object> T[] toArray(T[]);
 public abstract boolean add(E);
 public abstract boolean remove(java.lang.Object);
 public abstract boolean containsAll(java.util.Collection<?>);
 public abstract boolean addAll(java.util.Collection<? extends E>);
 public abstract boolean removeAll(java.util.Collection<?>);
 public abstract boolean retainAll(java.util.Collection<?>);
 public abstract void clear();
 public abstract boolean equals(java.lang.Object);
 public abstract int hashCode();
}

and same methods are also present in List interface:

public interface List extends Collection
{
 public abstract int size();
 public abstract boolean isEmpty();
 public abstract boolean contains(java.lang.Object);
 public abstract java.util.Iterator<E> iterator();
 public abstract java.lang.Object[] toArray();
 public abstract <T extends java/lang/Object> T[] toArray(T[]);
 public abstract boolean add(E);
 public abstract boolean remove(java.lang.Object);
 public abstract boolean containsAll(java.util.Collection<?>);
 public abstract boolean addAll(java.util.Collection<? extends E>);
 public abstract boolean removeAll(java.util.Collection<?>);
 public abstract boolean retainAll(java.util.Collection<?>);
 public abstract void clear();
 public abstract boolean equals(java.lang.Object);
 public abstract int hashCode();
}

Is it a requirement to write these methods again in List if it is already extending the Collection interface?

Answer 1

They're re-written so that they can be documented, in order to specify how the List refines the contract of these methods compared to the contract specified in the Collection interface.

For example, the add() method in List is documented to specify that the element is added to the end of the list. This can't be specified in Collection, since a Collection doesn't have a beginning and an end.

Answer 2

JavaDoc and API contracts change somewhat/ or become more specific, as you move down the inheritance heirarchy.

List re-declares these methods & gives them more specific JavaDoc.

Answer 3

Just for convenience.

Same mentioned in Docs

The List interface places additional stipulations, beyond those specified in the Collection interface, on the contracts of the iterator, add, remove, equals, and hashCode methods. Declarations for other inherited methods are also included here for convenience

Answer 4

Collection<T> is just a group of item. In itself it doesn't have any more requirements than holding references to the many items that are its members.

In the basic java api there is two main types of collections: List<T> and Set<T> .

List<T> have the extra requirement to maintain a certain order (insertion order, sorted order, ...) for all its items. So that if you request item N the list will always return the same item for N.

Set<T> does not offer any guarantee on order but offers guarantee on uniqueness of the items. An item A cannot be added twice to a Set, or will appear only once in a set.

You should acquaint yourself with the practice of "marker" interface. Serializable is one of those, and generally the basic example when talking about this. And List<T> and Set<T> are declared as such, they mark a collection as one or the other in order to inform the programmer of the behaviour they can expect from the collection they receive.

Please refer to Item 37 (Chapter 6) of "Effective Java" for a very good explanation on how this is better than using annotations.

And there is also the fact that myCollection instanceof MyInterface is faster than myCollection.getClass().isAnnotationPresent(MyAnnotation.class) or myCollection.getClass().getAnnotation(MyAnnotation.class) != null .

Answer 5

The signatures on the toArray methods suggest that you extracted this from the compiled .class files. The class file format specifies that the .class file does not repeat methods inherited from superinterfaces, so I suspect that whatever tool you used to obtain these was showing you a composite view; the methods aren't actually physically present on List .

Answer 6

A collection is just a collection of items.

A list, apart from holding list of items, adds information regarding sequence of stuff to it.

When you add an item to collection, you are just adding it. When you add an item to List, you can add at position n

When you remove an item from collection, you are just removing it. When you remove an item from List, you can remove at position n

When you want to get an item from collection, you have to iterate. When you want to get an item from List, you can get at position n

Answer 7

首先接口List继承所有Collection方法，因此Collection接口中存在的所有方法也将存在于List接口中，但List接口有额外的方法，（由ur self检查）描述列表的行为

Answer 8

It is mainly because of documentation purpose they have used like that.

For example

Collection#retainAll 

Retains only the elements in this collection that are contained in the specified collection (optional operation).

List#retainAll

Retains only the elements in this list that are contained in the specified collection (optional operation).

Only for java doc purpose they have used like that. But some of the methods behaviour itself changed.

For ex.add,remove

Method remove

In List, Removes the first occurrence of the specified element from this list, if it is present (optional operation).

In Collection , Removes a single instance of the specified element from this collection, if it is present (optional operation).

Through Java doc they have clearly indicate List implementations are ordered.