Package one.microstream.collections

Class FixedList<E>

  • All Implemented Interfaces:
    Iterable<E>, CapacityCarrying, ExtendedBag<E>, ExtendedCollection<E>, ExtendedList<E>, ExtendedSequence<E>, ReleasingCollection<E>, Sized, Sortable<E>, XGettingBag<E>, XGettingCollection<E>, XGettingList<E>, XGettingSequence<E>, XIndexIterable<E>, XIterable<E>, XJoinable<E>, XOrderingSequence<E>, XReplacingBag<E>, XReplacingCollection<E>, XSettingList<E>, XSettingSequence<E>, XSortableSequence<E>, Composition, Copyable
    public final class FixedList<E>
extends AbstractSimpleArrayCollection<E>
implements XSettingList<E>, Composition
    Full scale general purpose implementation of extended collection type XList.

    This array-backed implementation is optimal for all needs of a list that do not require frequent structural modification (insert or remove) of single elements before the end of the list.
    It is recommended to use this implementation as default list type until concrete performance deficiencies are identified. If used properly, this implementation has equal or massively superior performance to linked-list implementation is most cases.

    This implementation is NOT synchronized and thus should only be used by a single thread or in a thread-safe manner (i.e. read-only as soon as multiple threads access it).
    See SynchList wrapper class to use a list in a synchronized manner.

    Note that this List implementation does NOT keep track of modification count as JDK's collection implementations do (and thus never throws a ConcurrentModificationException), for two reasons:
    1.) It is already explicitly declared thread-unsafe and for single-thread (or thread-safe) use only.
    2.) The common modCount-concurrency exception behavior ("failfast") has buggy and inconsistent behavior by throwing ConcurrentModificationException even in single thread use, i.e. when iterating over a collection and removing more than one element of it without using the iterator's method.

    Current conclusion is that the JDK's failfast implementations buy unneeded (and even unreliable as stated by official guides) concurrency modification recognition at the cost of performance loss and even a bug when already used in a thread-safe manner.

    Also note that by being an extended collection, this implementation offers various functional and batch procedures to maximize internal iteration potential, eliminating the need to use the ill-conceived external iteration Iterator paradigm.

    Version:
    0.9, 2011-02-06