Inconsistency in Java Collection APIs

Question

First of all, I am unable to find an interface for Stack data structure. It exists, but the one I find extends a Vector which I would try to avoid using. So, if you really need a stack, would you recommend me implementing my own stack class that has-a a ArrayDeque internally or would you recommend me using the Stack class that extends the Vector? I am very disappointed that a good Stack interface is non-existent in Java.

Secondly, Queue provides, add(e), remove() and element() methods. On top of that, they also provide offer(e), poll() and peek() methods. The former throws exception, while the latter returns true or false or null. Which one would you use if the Queue you want to use is for a non-concurrent case?

score 3 · Answer 1 · edited Jun 20 '20 at 09:12

3

To answer your first "question:" Is there a drop-in replacement for Java Stack that is not synchronized?

And the second question: (I hate to have to say it, but) RTFD. Seriously.

public interface Queue<E> extends Collection<E>

... Each of these methods exists in two forms: one throws an exception if the operation fails, the other returns a special value (either null or false, depending on the operation). The latter form of the insert operation is designed specifically for use with capacity-restricted Queue implementations; in most implementations, insert operations cannot fail.

http://download.oracle.com/javase/7/docs/api/java/util/Queue.html

Neither set of methods has anything to do with concurrency. They simply allow you to choose between two programming styles (and hopefully, you're consistent!): do you want to have to check return values, or catch exceptions?

edited Jun 20 '20 at 09:12

Community

1
1

answered Nov 15 '11 at 02:55

Matt Ball

354,903
100
647
710

I already read that. But the fact is, in reality, when you your code pushes or pops something you know if it is not to work or not because you some kind of existence check before it. So, in practice, I find the return values useful only in the concurrent case where you don't know the result of the operation until runtime. – user855 Nov 15 '11 at 03:01
@ajay, the check doesn't happen before the operation, such a check would be able to read the future. The check comes after the attempt of the operation. Using one technique, you check a return value for an "error" result. Using the other technique, you catch an exception for an "error" result. You just have to choose which way you wan to detect errors. One way of detecting errors isn't better for a specific type of concurrency, both techniques are reporting the same "error" they are just doing it in different ways. – Edwin Buck Nov 15 '11 at 03:30

score 0 · Answer 2 · answered Nov 15 '11 at 03:04

Deque<E> Q = new LinkedList<E>();
Q.add(e);
Q.remove();
Q.element();

Deque<E> S = new LinkedList<E>();
S.push(e);
S.pop();
S.peek();

I think I would rather use these methods in the common scenarios. And when I have to worry about the success of the operation at runtime (example, concurrent case), I will go for the offer(E e, TimeUnit timeout) and poll(TimeUnit timeout) usage.

score 0 · Answer 3 · answered Nov 15 '11 at 06:51

Try the Apache Commons Collections API if the JDK collections API doesn't exactly meet your needs

From Apache ArrayStack documentation which seems to match your requirements:

An implementation of the Stack API that is based on an ArrayList instead of a Vector, so it is not synchronized to protect against multi-threaded access. The implementation is therefore operates faster in environments where you do not need to worry about multiple thread contention.

Inconsistency in Java Collection APIs

3 Answers3