Hash table and linked list implementation of the Set interface, jaroslav@1258: * with predictable iteration order. This implementation differs from jaroslav@1258: * HashSet in that it maintains a doubly-linked list running through jaroslav@1258: * all of its entries. This linked list defines the iteration ordering, jaroslav@1258: * which is the order in which elements were inserted into the set jaroslav@1258: * (insertion-order). Note that insertion order is not affected jaroslav@1258: * if an element is re-inserted into the set. (An element e jaroslav@1258: * is reinserted into a set s if s.add(e) is invoked when jaroslav@1258: * s.contains(e) would return true immediately prior to jaroslav@1258: * the invocation.) jaroslav@1258: * jaroslav@1258: *
This implementation spares its clients from the unspecified, generally jaroslav@1258: * chaotic ordering provided by {@link HashSet}, without incurring the jaroslav@1258: * increased cost associated with {@link TreeSet}. It can be used to jaroslav@1258: * produce a copy of a set that has the same order as the original, regardless jaroslav@1258: * of the original set's implementation: jaroslav@1258: *
jaroslav@1258: * void foo(Set s) {
jaroslav@1258: * Set copy = new LinkedHashSet(s);
jaroslav@1258: * ...
jaroslav@1258: * }
jaroslav@1258: *
jaroslav@1258: * This technique is particularly useful if a module takes a set on input,
jaroslav@1258: * copies it, and later returns results whose order is determined by that of
jaroslav@1258: * the copy. (Clients generally appreciate having things returned in the same
jaroslav@1258: * order they were presented.)
jaroslav@1258: *
jaroslav@1258: * This class provides all of the optional Set operations, and jaroslav@1258: * permits null elements. Like HashSet, it provides constant-time jaroslav@1258: * performance for the basic operations (add, contains and jaroslav@1258: * remove), assuming the hash function disperses elements jaroslav@1258: * properly among the buckets. Performance is likely to be just slightly jaroslav@1258: * below that of HashSet, due to the added expense of maintaining the jaroslav@1258: * linked list, with one exception: Iteration over a LinkedHashSet jaroslav@1258: * requires time proportional to the size of the set, regardless of jaroslav@1258: * its capacity. Iteration over a HashSet is likely to be more jaroslav@1258: * expensive, requiring time proportional to its capacity. jaroslav@1258: * jaroslav@1258: *
A linked hash set has two parameters that affect its performance: jaroslav@1258: * initial capacity and load factor. They are defined precisely jaroslav@1258: * as for HashSet. Note, however, that the penalty for choosing an jaroslav@1258: * excessively high value for initial capacity is less severe for this class jaroslav@1258: * than for HashSet, as iteration times for this class are unaffected jaroslav@1258: * by capacity. jaroslav@1258: * jaroslav@1258: *
Note that this implementation is not synchronized. jaroslav@1258: * If multiple threads access a linked hash set concurrently, and at least jaroslav@1258: * one of the threads modifies the set, it must be synchronized jaroslav@1258: * externally. This is typically accomplished by synchronizing on some jaroslav@1258: * object that naturally encapsulates the set. jaroslav@1258: * jaroslav@1258: * If no such object exists, the set should be "wrapped" using the jaroslav@1258: * {@link Collections#synchronizedSet Collections.synchronizedSet} jaroslav@1258: * method. This is best done at creation time, to prevent accidental jaroslav@1258: * unsynchronized access to the set:
jaroslav@1258: * Set s = Collections.synchronizedSet(new LinkedHashSet(...));jaroslav@1258: * jaroslav@1258: *
The iterators returned by this class's iterator method are jaroslav@1258: * fail-fast: if the set is modified at any time after the iterator jaroslav@1258: * is created, in any way except through the iterator's own remove jaroslav@1258: * method, the iterator will throw a {@link ConcurrentModificationException}. jaroslav@1258: * Thus, in the face of concurrent modification, the iterator fails quickly jaroslav@1258: * and cleanly, rather than risking arbitrary, non-deterministic behavior at jaroslav@1258: * an undetermined time in the future. jaroslav@1258: * jaroslav@1258: *
Note that the fail-fast behavior of an iterator cannot be guaranteed jaroslav@1258: * as it is, generally speaking, impossible to make any hard guarantees in the jaroslav@1258: * presence of unsynchronized concurrent modification. Fail-fast iterators jaroslav@1258: * throw ConcurrentModificationException on a best-effort basis. jaroslav@1258: * Therefore, it would be wrong to write a program that depended on this jaroslav@1258: * exception for its correctness: the fail-fast behavior of iterators jaroslav@1258: * should be used only to detect bugs. jaroslav@1258: * jaroslav@1258: *
This class is a member of the
jaroslav@1258: *
jaroslav@1258: * Java Collections Framework.
jaroslav@1258: *
jaroslav@1258: * @param