Why List<E> interface is additionally introduced in collection hierarchy? [duplicate]

Question

Below is the diagram, where, if we just consider the implementations of List,

1. AbstractList maintains the core behavior of list. To introduce the new implementation class MyList(say) one can inherit AbstractList and override(if necessary) required methods. By extending AbstractList. Additionally, class MyList is obeying the contract to behave like a list.

   class MyList extends AbstractList{..}
   

2. Users can use collection hierarchy, as,

   AbstractList l = new ArrayList<String>();
   l.add("one"); //execute ArrayList's add method
   

3. A class can also maintain composition relation with any list implementation(at runtime), by having

   AbstractList l;
   

   as member, that gets populated at runtime, with any list implementation.

So,

I would like to understand the clear reason, Why additionally interface List<E> is introduced?

note1: Intention is to understand, how to use interface. This not a duplicate question, because both abstract class and interface are used.I did not use the word 'instead of' or 'rather'

note2: Let us not get into java-8 default methods, as above collection hierarchy was designed with whatever was provided till java-7

Answer 1

Your question seems to stem from the wrong assumption that every List is also a subclass of AbstractList. While AbstractList offers versatile base implementations for a lot of methods, there might be reasons not to use this option.

It’s hard to find an example when looking to the public API only, but there is one: CopyOnWriteArrayList.

You will find much more once you understand that not every implementation is public, e.g. by looking at Collections.unmodifiableList and Collections.synchronizedList, both returning implementations not inheriting from AbstractList for a good reason. They have base classes which are more suitable to their task, UnmodifiableList extends UnmodifiableCollection and SynchronizedList extends SynchronizedCollection.

There can be other, application-specific reasons not to subclass AbstractList, in the end, the decision to make the entire Collection-API interface-based is fundamental and there is no reason to make an exception for List. It’s not different to why you should use the Collection interface instead of AbstractCollection or the Set interface instead of AbstractSet…

Regarding how to use it… If it is about parameters or heap variables which ought to offer the maximum flexibility, of course, you should always use the least specific type that is required for the operation, e.g. the List interface, if it is required that the provided Collection has List semantic. As said, there are List types which do not extend AbstractList.

If it is about local variables within an implementation code, you might declare a variable to match the type of the actual implementation, e.g. ArrayList<X> l=new ArrayList<>(); to reduce the number of different types which occur in this code. But that still implies that there is no reason to refer to AbstractList. The only place where a reference is to AbstractList is feasible is in the extends AbstractList clause…

Answer 2

In both of your code snippets, the use of AbstractList is discouraged.¹ The correct usage is to put the new instance of list in a List variable.

The abstract classes AbstractList and AbstractSequentialList are provided for the convenience of implementers (i.e. library writers) of list-like containers, by providing default implementations(*) for some of the instance methods, in an effort to reduce code duplication.

_{(*)There is an ongoing, legitimate debate on what are the (i) preferred-, (ii) tolerable- and (iii) discouraged-ways of providing default implementations of instance methods in the Java language. Please see some of the other questions asked by overexchange for a starting point.}

Every list-like container must implement the List interface directly or indirectly, for them to be usable by other applications in a list-like manner. Inheritance from AbstractList or AbstractSequentialList is optional.

Likewise, applications that would like to accept a list-like container should accept a List. It should not require an AbstractList or AbstractSequentialList because it would disqualify some list-like containers.

As to the motivation for naming the interface List as is, it is likely² the decision of some influential Java founding fathers that decided that interfaces shall not have any naming decorations that indicate they are interfaces (i.e. not backed by any concrete implementations). That position is debatable but it will stay with the Java language forever.

¹ _{"discouraged" is used as an euphemism for "plainly wrong."}

² _{Citation needed. Feel free to edit this post to add the necessary reference, or to remove this paragraph if this is incorrect.}

Answer 3

I would like to understand the clear reason, Why additionally interface List is introduced?

In Java, types form a directed acyclic graph, but classes form a tree. As such, types are strictly more flexible than classes. When designing APIs, you should prefer uses non-class types as much as possible for your parameters and your return types. And pretty much your only choice in Java for a non-class type is an interface.

In other words, interfaces are nicer for users of your types.

However (at least prior to Java 8), if you actually want these types to have an implementation, you need a (possibly abstract) class. So classes are nicer for implementors of your types.

In order to satisfy both users and implementors, the designers of the List API provided both a List interface and an AbstractList abstract class.

Funnily enough, today with Java 8, interfaces can have so called "default implementations", thus removing the need for the AbstractList abstract class. So your question should be phrased the other way: "Why was the additional abstract class AbstractList introduced?" and the answer would have been "due to historical reasons, old Javas did not have default methods."