Queues typically, but do not necessarily order elements in a - * FIFO (first-in-first-out) manner. Among the exceptions are priority - * queues, that order elements in accord with supplied - * Comparators. Every Queue implementation must specify its ordering - * guarantees, - * - *
The offer method adds an element if possible, - * otherwise returning false. This differs from the - * Collections.add method, that throws an unchecked exception upon - * failure. It is designed for use in collections in which failure to - * add is a normal, rather than exceptional occurrence, for example, - * in fixed-capacity queues. - * - *
The remove and poll methods delete and return - * an element in accord with the implementation's ordering policies -- - * for example, in FIFO queues, it will return the oldest element. - * The remove and poll differ only in their behavior - * when the queue is empty: poll returns null while - * remove throws an exception. These are designed for usage - * contexts in which emptiness is considered to be normal versus - * exceptional. - * - *
The element and peek methods return but do - * not delete the element that would be obtained by a call to - * remove and poll respectively. - * - *
The Queue interface does not define blocking queue methods - * (i.e., those that wait for elements to appear and/or for space to - * be available) that are common in concurrent programming. These are - * defined in the extended java.util.concurrent.BlockingQueue - * interface. - * - *
Queue implementations generally do not allow insertion of - * null. Even in those that allow it, it is a very bad idea - * to do so, since null is also used as a sentinel by - * poll to indicate that no elements exist. - **/ + * A collection designed for holding elements prior to processing. + * Besides basic {@link java.util.Collection Collection} operations, + * queues provide additional insertion, extraction, and inspection + * operations. Each of these methods exists in two forms: one throws + * an exception if the operation fails, the other returns a special + * value (either {@code null} or {@code false}, depending on the + * operation). The latter form of the insert operation is designed + * specifically for use with capacity-restricted {@code Queue} + * implementations; in most implementations, insert operations cannot + * fail. + * + *
| + * | Throws exception | + *Returns special value | + *
| Insert | + *{@link Queue#add add(e)} | + *{@link Queue#offer offer(e)} | + *
| Remove | + *{@link Queue#remove remove()} | + *{@link Queue#poll poll()} | + *
| Examine | + *{@link Queue#element element()} | + *{@link Queue#peek peek()} | + *
Queues typically, but do not necessarily, order elements in a + * FIFO (first-in-first-out) manner. Among the exceptions are + * priority queues, which order elements according to a supplied + * comparator, or the elements' natural ordering, and LIFO queues (or + * stacks) which order the elements LIFO (last-in-first-out). + * Whatever the ordering used, the head of the queue is that + * element which would be removed by a call to {@link #remove() } or + * {@link #poll()}. In a FIFO queue, all new elements are inserted at + * the tail of the queue. Other kinds of queues may use + * different placement rules. Every {@code Queue} implementation + * must specify its ordering properties. + * + *
The {@link #offer offer} method inserts an element if possible, + * otherwise returning {@code false}. This differs from the {@link + * java.util.Collection#add Collection.add} method, which can fail to + * add an element only by throwing an unchecked exception. The + * {@code offer} method is designed for use when failure is a normal, + * rather than exceptional occurrence, for example, in fixed-capacity + * (or "bounded") queues. + * + *
The {@link #remove()} and {@link #poll()} methods remove and + * return the head of the queue. + * Exactly which element is removed from the queue is a + * function of the queue's ordering policy, which differs from + * implementation to implementation. The {@code remove()} and + * {@code poll()} methods differ only in their behavior when the + * queue is empty: the {@code remove()} method throws an exception, + * while the {@code poll()} method returns {@code null}. + * + *
The {@link #element()} and {@link #peek()} methods return, but do + * not remove, the head of the queue. + * + *
The {@code Queue} interface does not define the blocking queue + * methods, which are common in concurrent programming. These methods, + * which wait for elements to appear or for space to become available, are + * defined in the {@link java.util.concurrent.BlockingQueue} interface, which + * extends this interface. + * + *
{@code Queue} implementations generally do not allow insertion + * of {@code null} elements, although some implementations, such as + * {@link LinkedList}, do not prohibit insertion of {@code null}. + * Even in the implementations that permit it, {@code null} should + * not be inserted into a {@code Queue}, as {@code null} is also + * used as a special return value by the {@code poll} method to + * indicate that the queue contains no elements. + * + *
{@code Queue} implementations generally do not define + * element-based versions of methods {@code equals} and + * {@code hashCode} but instead inherit the identity based versions + * from class {@code Object}, because element-based equality is not + * always well-defined for queues with the same elements but different + * ordering properties. + * + * + *
This interface is a member of the
+ *
+ * Java Collections Framework.
+ *
+ * @see java.util.Collection
+ * @see LinkedList
+ * @see PriorityQueue
+ * @see java.util.concurrent.LinkedBlockingQueue
+ * @see java.util.concurrent.BlockingQueue
+ * @see java.util.concurrent.ArrayBlockingQueue
+ * @see java.util.concurrent.LinkedBlockingQueue
+ * @see java.util.concurrent.PriorityBlockingQueue
+ * @since 1.5
+ * @author Doug Lea
+ * @param