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 + * A Collection designed for holding elements prior to processing. + * Besides basic {@link Collection} operations, queues provide + * additional insertion, extraction, and inspection operations. + * + *
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 comparators, or + * the elements natural ordering. Every Queue implementation must specify + * its ordering guarantees. + * + *
The {@link #offer(E)} method adds an element if possible, otherwise + * returning false. This differs from the {@link + * Collections#add(Object)} method, which 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. + * in fixed-capacity (or “bounded”) 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 {@link #remove()} and {@link #poll()} methods remove and return an + * element in accord with the implementation's ordering policy. For example, + * in FIFO queues, they remove and return the oldest element in the queue. + * The remove() and poll() methods differ only in their + * behavior when the queue is empty: the remove() method throws an + * exception, while the poll() method returns null. * - *
The element and peek methods return but do + *
The {@link #element()} and {@link #peek()} methods return but do * not delete the element that would be obtained by a call to - * remove and poll respectively. + * the remove and poll methods 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. - **/ + *
The 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. + * + *
Queue implementations generally do not allow insertion of + * null elements. Even in the few implementations that permit it, + * it is a bad idea, as null is also used as a special return value + * by the poll method to indicate that the queue contains no + * elements. + * + *
This interface is a member of the
+ *
+ * Java Collections Framework.
+ *
+ * @see Collection
+ * @see LinkedList
+ * @see PriorityQueue
+ * @see LinkedQueue
+ * @see java.util.concurrent.BlockingQueue
+ * @see java.util.concurrent.ArrayBlockingQueue
+ * @see java.util.concurrent.LinkedBlockingQueue
+ * @see java.util.concurrent.PriorityBlockingQueue
+ */
public interface Queue