1 |
+ |
/* |
2 |
+ |
* Written by Doug Lea with assistance from members of JCP JSR-166 |
3 |
+ |
* Expert Group and released to the public domain. Use, modify, and |
4 |
+ |
* redistribute this code in any way without acknowledgement. |
5 |
+ |
*/ |
6 |
+ |
|
7 |
|
package java.util; |
8 |
|
|
9 |
|
/** |
10 |
< |
* Queues are Collections supporting additional basic insertion, |
11 |
< |
* extraction, and inspection operations. |
12 |
< |
* |
13 |
< |
* <p> Queues typically, but do not necessarily order elements in a |
14 |
< |
* FIFO (first-in-first-out) manner. Among the exceptions are priority |
15 |
< |
* queues, that order elements in accord with supplied |
16 |
< |
* Comparators. Every Queue implementation must specify its ordering |
17 |
< |
* guarantees, |
18 |
< |
* |
19 |
< |
* <p> The <tt>offer</tt> method adds an element if possible, |
20 |
< |
* otherwise returning <tt>false</tt>. This differs from the |
21 |
< |
* Collections.add method, that throws an unchecked exception upon |
22 |
< |
* failure. It is designed for use in collections in which failure to |
23 |
< |
* add is a normal, rather than exceptional occurrence, for example, |
24 |
< |
* in fixed-capacity queues. |
25 |
< |
* |
26 |
< |
* <p> The <tt>remove</tt> and <tt>poll</tt> methods delete and return |
27 |
< |
* an element in accord with the implementation's ordering policies -- |
28 |
< |
* for example, in FIFO queues, it will return the oldest element. |
29 |
< |
* The <tt>remove</tt> and <tt>poll</tt> differ only in their behavior |
30 |
< |
* when the queue is empty: <tt>poll</tt> returns <tt>null</tt> while |
31 |
< |
* <tt>remove</tt> throws an exception. These are designed for usage |
32 |
< |
* contexts in which emptiness is considered to be normal versus |
33 |
< |
* exceptional. |
34 |
< |
* |
35 |
< |
* <p> The <tt>element</tt> and <tt>peek</tt> methods return but do |
36 |
< |
* not delete the element that would be obtained by a call to |
37 |
< |
* <tt>remove</tt> and <tt>poll</tt> respectively. |
38 |
< |
* |
39 |
< |
* <p> The Queue interface does not define blocking queue methods |
40 |
< |
* (i.e., those that wait for elements to appear and/or for space to |
41 |
< |
* be available) that are common in concurrent programming. These are |
42 |
< |
* defined in the extended java.util.concurrent.BlockingQueue |
43 |
< |
* interface. |
44 |
< |
* |
45 |
< |
* <p> Queue implementations generally do not allow insertion of |
46 |
< |
* <tt>null</tt>. Even in those that allow it, it is a very bad idea |
47 |
< |
* to do so, since <tt>null</tt> is also used as a sentinel by |
48 |
< |
* <tt>poll</tt> to indicate that no elements exist. |
49 |
< |
**/ |
10 |
> |
* A collection designed for holding elements prior to processing. |
11 |
> |
* Besides basic {@link java.util.Collection Collection} operations, queues provide |
12 |
> |
* additional insertion, extraction, and inspection operations. |
13 |
> |
* |
14 |
> |
* <p>Queues typically, but do not necessarily, order elements in a |
15 |
> |
* FIFO (first-in-first-out) manner. Among the exceptions are |
16 |
> |
* priority queues, which order elements according to a supplied |
17 |
> |
* comparator, or the elements' natural ordering, and LIFO queues (or |
18 |
> |
* stacks) which order the elements LIFO (last-in-first-out). |
19 |
> |
* Whatever the ordering used, the <em>head</em> of the queue is that |
20 |
> |
* element which would be removed by a call to {@link #remove() } or |
21 |
> |
* {@link #poll()}. In a FIFO queue, all new elements are inserted at |
22 |
> |
* the <em> tail</em> of the queue. Other kinds of queues may use |
23 |
> |
* different placement rules. Every <tt>Queue</tt> implementation |
24 |
> |
* must specify its ordering properties. |
25 |
> |
* |
26 |
> |
* <p>The {@link #offer offer} method inserts an element if possible, |
27 |
> |
* otherwise returning <tt>false</tt>. This differs from the {@link |
28 |
> |
* java.util.Collection#add Collection.add} method, which can fail to |
29 |
> |
* add an element only by throwing an unchecked exception. The |
30 |
> |
* <tt>offer</tt> method is designed for use when failure is a normal, |
31 |
> |
* rather than exceptional occurrence, for example, in fixed-capacity |
32 |
> |
* (or "bounded") queues. |
33 |
> |
* |
34 |
> |
* <p>The {@link #remove()} and {@link #poll()} methods remove and |
35 |
> |
* return the head of the queue. |
36 |
> |
* Exactly which element is removed from the queue is a |
37 |
> |
* function of the queue's ordering policy, which differs from |
38 |
> |
* implementation to implementation. The <tt>remove()</tt> and |
39 |
> |
* <tt>poll()</tt> methods differ only in their behavior when the |
40 |
> |
* queue is empty: the <tt>remove()</tt> method throws an exception, |
41 |
> |
* while the <tt>poll()</tt> method returns <tt>null</tt>. |
42 |
> |
* |
43 |
> |
* <p>The {@link #element()} and {@link #peek()} methods return, but do |
44 |
> |
* not remove, the head of the queue. |
45 |
> |
* |
46 |
> |
* <p>The <tt>Queue</tt> interface does not define the <i>blocking queue |
47 |
> |
* methods</i>, which are common in concurrent programming. These methods, |
48 |
> |
* which wait for elements to appear or for space to become available, are |
49 |
> |
* defined in the {@link java.util.concurrent.BlockingQueue} interface, which |
50 |
> |
* extends this interface. |
51 |
> |
* |
52 |
> |
* <p><tt>Queue</tt> implementations generally do not allow insertion |
53 |
> |
* of <tt>null</tt> elements, although some implementations, such as |
54 |
> |
* {@link LinkedList}, do not prohibit insertion of <tt>null</tt>. |
55 |
> |
* Even in the implementations that permit it, <tt>null</tt> should |
56 |
> |
* not be inserted into a <tt>Queue</tt>, as <tt>null</tt> is also |
57 |
> |
* used as a special return value by the <tt>poll</tt> method to |
58 |
> |
* indicate that the queue contains no elements. |
59 |
> |
* |
60 |
> |
* <p><tt>Queue</tt> implementations generally do not define |
61 |
> |
* element-based versions of methods <tt>equals</tt> and |
62 |
> |
* <tt>hashCode</tt> but instead inherit the identity based versions |
63 |
> |
* from class <tt>Object</tt>, because element-based equality is not |
64 |
> |
* always well-defined for queues with the same elements but different |
65 |
> |
* ordering properties. |
66 |
> |
* |
67 |
> |
* |
68 |
> |
* <p>This interface is a member of the |
69 |
> |
* <a href="{@docRoot}/../guide/collections/index.html"> |
70 |
> |
* Java Collections Framework</a>. |
71 |
> |
* |
72 |
> |
* @see java.util.Collection |
73 |
> |
* @see LinkedList |
74 |
> |
* @see PriorityQueue |
75 |
> |
* @see java.util.concurrent.LinkedBlockingQueue |
76 |
> |
* @see java.util.concurrent.BlockingQueue |
77 |
> |
* @see java.util.concurrent.ArrayBlockingQueue |
78 |
> |
* @see java.util.concurrent.LinkedBlockingQueue |
79 |
> |
* @see java.util.concurrent.PriorityBlockingQueue |
80 |
> |
* @since 1.5 |
81 |
> |
* @author Doug Lea |
82 |
> |
*/ |
83 |
|
public interface Queue<E> extends Collection<E> { |
84 |
|
|
85 |
|
/** |
86 |
< |
* Add the given object to this queue if possible. |
87 |
< |
* @param x the object to add |
88 |
< |
* @return true if successful |
89 |
< |
**/ |
90 |
< |
public boolean offer(E x); |
86 |
> |
* Inserts the specified element into this queue, if possible. When |
87 |
> |
* using queues that may impose insertion restrictions (for |
88 |
> |
* example capacity bounds), method <tt>offer</tt> is generally |
89 |
> |
* preferable to method {@link Collection#add}, which can fail to |
90 |
> |
* insert an element only by throwing an exception. |
91 |
> |
* |
92 |
> |
* @param o the element to insert. |
93 |
> |
* @return <tt>true</tt> if it was possible to add the element to |
94 |
> |
* this queue, else <tt>false</tt> |
95 |
> |
*/ |
96 |
> |
boolean offer(E o); |
97 |
|
|
98 |
|
/** |
99 |
< |
* Delete and return an object from the queue if one is available. |
100 |
< |
* @return the object, or null if the queue is empty. |
101 |
< |
**/ |
102 |
< |
public E poll(); |
99 |
> |
* Retrieves and removes the head of this queue, or <tt>null</tt> |
100 |
> |
* if this queue is empty. |
101 |
> |
* |
102 |
> |
* @return the head of this queue, or <tt>null</tt> if this |
103 |
> |
* queue is empty. |
104 |
> |
*/ |
105 |
> |
E poll(); |
106 |
|
|
107 |
|
/** |
108 |
< |
* Delete and return the element produced by poll, if the queue is |
109 |
< |
* not empty. |
110 |
< |
* @return an element |
111 |
< |
* @throws NoSuchElementException if empty |
112 |
< |
**/ |
113 |
< |
public E remove() throws NoSuchElementException; |
108 |
> |
* Retrieves and removes the head of this queue. This method |
109 |
> |
* differs from the <tt>poll</tt> method in that it throws an |
110 |
> |
* exception if this queue is empty. |
111 |
> |
* |
112 |
> |
* @return the head of this queue. |
113 |
> |
* @throws NoSuchElementException if this queue is empty. |
114 |
> |
*/ |
115 |
> |
E remove(); |
116 |
|
|
117 |
|
/** |
118 |
< |
* Return but do not delete the element that will be returned by |
119 |
< |
* the next call to poll. |
120 |
< |
* @return an element, or null if empty |
121 |
< |
**/ |
122 |
< |
public E peek(); |
118 |
> |
* Retrieves, but does not remove, the head of this queue, |
119 |
> |
* returning <tt>null</tt> if this queue is empty. |
120 |
> |
* |
121 |
> |
* @return the head of this queue, or <tt>null</tt> if this queue |
122 |
> |
* is empty. |
123 |
> |
*/ |
124 |
> |
E peek(); |
125 |
|
|
126 |
|
/** |
127 |
< |
* Return but do not delete the element that will be returned by |
128 |
< |
* the next call to poll, if the queue is not empty. |
129 |
< |
* @return an element |
130 |
< |
* @throws NoSuchElementException if empty |
131 |
< |
**/ |
132 |
< |
public E element() throws NoSuchElementException; |
127 |
> |
* Retrieves, but does not remove, the head of this queue. This method |
128 |
> |
* differs from the <tt>peek</tt> method only in that it throws an |
129 |
> |
* exception if this queue is empty. |
130 |
> |
* |
131 |
> |
* @return the head of this queue. |
132 |
> |
* @throws NoSuchElementException if this queue is empty. |
133 |
> |
*/ |
134 |
> |
E element(); |
135 |
|
} |