--- jsr166/src/main/java/util/Queue.java 2003/06/23 02:26:15 1.6 +++ jsr166/src/main/java/util/Queue.java 2003/07/28 19:53:49 1.9 @@ -7,37 +7,37 @@ package java.util; /** - * A Collection designed for holding elements prior to processing. + * A collection designed for holding elements prior to processing. * Besides basic {@link Collection} operations, queues provide * additional insertion, extraction, and inspection operations. -0 * + * *
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. Every Queue - * implementation must specify its ordering guarantees. + * 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()}. + * 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 (or “bounded”) queues. - - * - *
The {@link #remove()} and {@link #poll()} methods remove and return an - * element in accord with the implementation's ordering policy. - * Exactly which element is removed from the queue is a function - * of the queue's ordering policy, which differs from implementation - * to implementation. Possible orderings include (but are not limited - * to) first-in-first-out (FIFO), last-in-first-out (LIFO), element priority, and arbitrary. - * 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 {@link #element()} and {@link #peek()} methods return but do - * not delete the element that would be obtained by a call to - * the remove and poll methods respectively. + * 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 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 {@link #element()} and {@link #peek()} methods return, but do + * not delete, the head of the queue. * *
The Queue interface does not define the blocking queue * methods, which are common in concurrent programming. These methods, @@ -45,13 +45,13 @@ package java.util; * defined in the {@link java.util.concurrent.BlockingQueue} interface, which * extends this interface. * - *
Queue implementations generally do not allow insertion of - * null elements, although some implementations, such as + *
Queue implementations generally do not allow insertion + * of null elements, although some implementations, such as * {@link LinkedList}, do not prohibit insertion of null. - * Even in the implementations that permit it, null should not be inserted into - * a Queue, as null is also used as a special return value - * by the poll method to indicate that the queue contains no - * elements. + * Even in the implementations that permit it, null should + * not be inserted into a Queue, as null is also + * used as a special return value by the poll method to + * indicate that the queue contains no elements. * *