java.lang.Objectjava.util.AbstractCollection
java.util.AbstractList
All Implemented Interfaces:
List, Collection
Direct Known Subclasses:
SubList, ArrayList, SubList, COWSubList, RandomAccessSubList, LinkVector, RoleUnresolvedList, LinkedList, ArrayList, RoleList, Vector, SingletonList, DConnector, AttributeList, AbstractSequentialList, EmptyList, Stack, CopiesList
To implement an unmodifiable list, the programmer needs only to extend this class and provide implementations for the #get(int) and size() methods.
To implement a modifiable list, the programmer must additionally override the set(int, E) method (which otherwise throws an {@code UnsupportedOperationException}). If the list is variable-size the programmer must additionally override the add(int, E) and #remove(int) methods.
The programmer should generally provide a void (no argument) and collection constructor, as per the recommendation in the Collection interface specification.
Unlike the other abstract collection implementations, the programmer does not have to provide an iterator implementation; the iterator and list iterator are implemented by this class, on top of the "random access" methods: #get(int) , set(int, E) , add(int, E) and #remove(int) .
The documentation for each non-abstract method in this class describes its implementation in detail. Each of these methods may be overridden if the collection being implemented admits a more efficient implementation.
This class is a member of the Java Collections Framework.
Josh - BlochNeal - Gafter1.2 - | Field Summary | ||
|---|---|---|
| protected transient int | modCount | The number of times this list has been structurally modified.
Structural modifications are those that change the size of the
list, or otherwise perturb it in such a fashion that iterations in
progress may yield incorrect results.
This field is used by the iterator and list iterator implementation returned by the {@code iterator} and {@code listIterator} methods. If the value of this field changes unexpectedly, the iterator (or list iterator) will throw a {@code ConcurrentModificationException} in response to the {@code next}, {@code remove}, {@code previous}, {@code set} or {@code add} operations. This provides fail-fast behavior, rather than non-deterministic behavior in the face of concurrent modification during iteration. Use of this field by subclasses is optional. If a subclass wishes to provide fail-fast iterators (and list iterators), then it merely has to increment this field in its {@code add(int, E)} and {@code remove(int)} methods (and any other methods that it overrides that result in structural modifications to the list). A single call to {@code add(int, E)} or {@code remove(int)} must add no more than one to this field, or the iterators (and list iterators) will throw bogus {@code ConcurrentModificationExceptions}. If an implementation does not wish to provide fail-fast iterators, this field may be ignored. |
| Constructor: |
|---|
|
| Method from java.util.AbstractList Summary: |
|---|
| add, add, addAll, clear, equals, get, hashCode, indexOf, iterator, lastIndexOf, listIterator, listIterator, remove, removeRange, set, subList |
| Methods from java.util.AbstractCollection: |
|---|
| add, addAll, clear, contains, containsAll, isEmpty, iterator, remove, removeAll, retainAll, size, toArray, toArray, toString |
| Methods from java.lang.Object: |
|---|
| clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait |
| Method from java.util.AbstractList Detail: |
|---|
Lists that support this operation may place limitations on what elements may be added to this list. In particular, some lists will refuse to add null elements, and others will impose restrictions on the type of elements that may be added. List classes should clearly specify in their documentation any restrictions on what elements may be added. This implementation calls {@code add(size(), e)}. Note that this implementation throws an {@code UnsupportedOperationException} unless add(int, E) is overridden. |
This implementation always throws an {@code UnsupportedOperationException}. |
This implementation gets an iterator over the specified collection and iterates over it, inserting the elements obtained from the iterator into this list at the appropriate position, one at a time, using {@code add(int, E)}. Many implementations will override this method for efficiency. Note that this implementation throws an {@code UnsupportedOperationException} unless add(int, E) is overridden. |
This implementation calls {@code removeRange(0, size())}. Note that this implementation throws an {@code UnsupportedOperationException} unless {@code remove(int index)} or {@code removeRange(int fromIndex, int toIndex)} is overridden. |
This implementation first checks if the specified object is this list. If so, it returns {@code true}; if not, it checks if the specified object is a list. If not, it returns {@code false}; if so, it iterates over both lists, comparing corresponding pairs of elements. If any comparison returns {@code false}, this method returns {@code false}. If either iterator runs out of elements before the other it returns {@code false} (as the lists are of unequal length); otherwise it returns {@code true} when the iterations complete. |
|
This implementation uses exactly the code that is used to define the list hash function in the documentation for the List#hashCode method. |
This implementation first gets a list iterator (with {@code listIterator()}). Then, it iterates over the list until the specified element is found or the end of the list is reached. |
This implementation returns a straightforward implementation of the iterator interface, relying on the backing list's {@code size()}, {@code get(int)}, and {@code remove(int)} methods. Note that the iterator returned by this method will throw an UnsupportedOperationException in response to its {@code remove} method unless the list's {@code remove(int)} method is overridden. This implementation can be made to throw runtime exceptions in the face of concurrent modification, as described in the specification for the (protected) #modCount field. |
This implementation first gets a list iterator that points to the end of the list (with {@code listIterator(size())}). Then, it iterates backwards over the list until the specified element is found, or the beginning of the list is reached. |
This implementation returns {@code listIterator(0)}. |
This implementation returns a straightforward implementation of the {@code ListIterator} interface that extends the implementation of the {@code Iterator} interface returned by the {@code iterator()} method. The {@code ListIterator} implementation relies on the backing list's {@code get(int)}, {@code set(int, E)}, {@code add(int, E)} and {@code remove(int)} methods. Note that the list iterator returned by this implementation will throw an UnsupportedOperationException in response to its {@code remove}, {@code set} and {@code add} methods unless the list's {@code remove(int)}, {@code set(int, E)}, and {@code add(int, E)} methods are overridden. This implementation can be made to throw runtime exceptions in the face of concurrent modification, as described in the specification for the (protected) #modCount field. |
This implementation always throws an {@code UnsupportedOperationException}. |
This method is called by the {@code clear} operation on this list and its subLists. Overriding this method to take advantage of the internals of the list implementation can substantially improve the performance of the {@code clear} operation on this list and its subLists. This implementation gets a list iterator positioned before {@code fromIndex}, and repeatedly calls {@code ListIterator.next} followed by {@code ListIterator.remove} until the entire range has been removed. Note: if {@code ListIterator.remove} requires linear time, this implementation requires quadratic time. |
This implementation always throws an {@code UnsupportedOperationException}. |
This implementation returns a list that subclasses {@code AbstractList}. The subclass stores, in private fields, the offset of the subList within the backing list, the size of the subList (which can change over its lifetime), and the expected {@code modCount} value of the backing list. There are two variants of the subclass, one of which implements {@code RandomAccess}. If this list implements {@code RandomAccess} the returned list will be an instance of the subclass that implements {@code RandomAccess}. The subclass's {@code set(int, E)}, {@code get(int)}, {@code add(int, E)}, {@code remove(int)}, {@code addAll(int, Collection)} and {@code removeRange(int, int)} methods all delegate to the corresponding methods on the backing abstract list, after bounds-checking the index and adjusting for the offset. The {@code addAll(Collection c)} method merely returns {@code addAll(size, c)}. The {@code listIterator(int)} method returns a "wrapper object" over a list iterator on the backing list, which is created with the corresponding method on the backing list. The {@code iterator} method merely returns {@code listIterator()}, and the {@code size} method merely returns the subclass's {@code size} field. All methods first check to see if the actual {@code modCount} of the backing list is equal to its expected value, and throw a {@code ConcurrentModificationException} if it is not. |