/* * Written by Doug Lea with assistance from members of JCP JSR-166 * Expert Group and released to the public domain, as explained at * http://creativecommons.org/publicdomain/zero/1.0/ */ package java.util; /** * A collection designed for holding elements prior to processing. * Besides basic {@link 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 #add(Object) add(e)} | *{@link #offer(Object) offer(e)} | *
Remove | *{@link #remove() remove()} | *{@link #poll() poll()} | *
Examine | *{@link #element() element()} | *{@link #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.
*
* @since 1.5
* @author Doug Lea
* @param