We Keep Coding

Are Java's collections interface and class hierarchy ill done?

I came to know that in Java, LinkedList class implements both Deque and List interfaces.
And this was somewhat confusing to me.
In computer science syllabus, I was never taught that queue can be a list, or more precisely queue can behave like a list. That is, there is stuff that lists can do, but queues can't. But the list can behave like a queue. For example, List interface has the following methods:
add(E e)
add(int index, E element)
But Queue has only the following:
add(E e)
So clearly Queue is not allowed to insert at specific index, which is allowed in List. The same is the case with other operations like Queue.remove() vs. List.remove(int index), List.get(int index) vs. Queue.peek().
In other words, list is a more generalized data structure and can emulate Queue.
Now being capable to emulate is different from having a contract subset. That is, Queue disallows certain operations (indexing) of Listand allows certain operations done only in a particular manner (insert only at the tail and remove only from the head). So Queue does not really do "addition" to the contracts of List. That is precisely why Queue does not extend List in Java collections framework, but both extend Collection interface. I believe that is also why it's incorrect for any class to implement both, as Queue's contract conflicts with the contract of List (which is why they fork out from Collection interface separately). However, LinkedList implements both the interfaces.
I also came across this answer:
The LinkedList implementation happens to satisfy the Deque contract, so why not make it implement the interface?
I still don't get how we can say "LinkedList implementation happens to satisfy the Deque contract". The concept of a queue does not allow insertion at an arbitrary index. Hence, the Queue interface does not have such methods.
However we can only enforce contracts through interfaces and cannot disallow implementation of certain methods. Being list (having "List" in its name), I feel it's not correct to have queue methods peek(), pop() and add(int index, E element) in LinkedList.
I believe, instead we should have separate class LinkedQueue which can have linked implementation for queue, similar to LinkedBlockingQueue which contains linked implementation of BlockingQueue.
Also note that LinkedList is the only class which inherits from both families of lists and queues, that is, there is no other class which implements both List and Queue (AFAIK). Can this be indication that LinkedList is ill done?
Am I plain wrong and thinking unnecessarily?

You're entirely missing the point of programming to interface.
If you need a Queue, you never write:
LinkedList<String> queue = new LinkedList<>();
Because, you're right, that would allow you to use non-queue methods. Instead, you program to the interface like this:
Queue<String> queue = new LinkedList<>();
Now you only have access to the 6 Queue methods (and all the Collection methods). So, even though LinkedList implements more methods, you no longer have access to them.
So, if you need a Queue, you choose the implementation of the Queue interface that best suits the performance, storage, and access characteristics you need, e.g.
LinkedList uses more memory, but it shrinks when queue is emptied.
ArrayDeque uses less memory, but it doesn't shrink.
PriorityQueue is a non-FIFO queue with element priority.
ConcurrentLinkedQueue, ConcurrentLinkedDeque supports multi-threaded concurrent access.
and more...
I was never taught that queue can be a list, or more precisely queue can behave like a list.
Remember that implements defines a behaves like relationship. A LinkedList behaves like a List. A LinkedList behaves like a Deque. A LinkedList behaves like a Queue.
But just because LinkedList behaves like all of those, doesn't mean that List behaves like a Queue or that Queue behaves like a List. They do not.
The behaves like relation only goes one way.

#Andreas's answer is excellent, so mine targets your arguments about what you were or were not taught:
In computer science syllabus, I was never taught that queue can be a list or more precisely queue can behave like a list
A queue is not just any list, but a special kind of list, with its own special properties and constraints.
That is, there is stuff that lists can do, but queues can't.
No, List can do nothing. It provides possibilities to be implemented by a class and if that class decides to implement them then that class can do all that stuff.
But the list can behave like a queue.
No, List does not behave; it only suggests behaviors and classes that implement it can accept all or a subset of them or they can define new ones.

LinkedList is a class that implements both List and Deque interfaces. Each one of these interfaces defines a contract with operations, and in these contracts it is specified what these operations must do. However, it is not specified how these operations are supposed to work.
LinkedList is a class that implements both List and Deque interfaces. So, despite the suffix List is part of the name of the LinkedList class, LinkedList is actually both a List and a Deque, because it implements all of the operations that are defined in the List and Deque interfaces.
So LinkedList is a a List, and it also is a Deque. This doesn't mean that a List should be a Deque, or that a Deque should be a List.
For example, look at the following interfaces:
public interface BloodDrinker {
void drinkBlood();
}
public interface FlyingInsect {
void flyAround();
}
Each one of the interfaces above has a single operation and defines a contract. The drinkBlood operation defines what a BloodDrinker must do, but not how. Same applies for a FlyingInsect: its flyAround operation defines what it must do, but not how.
Now consider the Mosquito class:
public class Mosquito implements FlyingInsect, BloodDrinker {
public void flyAround() {
// fly by moving wings,
// buzzing and bothering everyone around
}
public void drinkBlood() {
// drink blood by biting other animals:
// suck their blood and inject saliva
}
}
Now, this means that a Mosquito is both a FlyingInsect and a BloodDrinker, but why would a blood drinker necessarily be a flying insect, or a flying insect necessarily be a blood drinker? For example, vampires are blood drinkers, but not flying insects, while butterflies are flying insects, but not blood drinkers.
Now, with regard to your argument about Queue disallowing certain List's operations (indexing), and only allowing addition/removal on its ends in a FIFO fashion... I don't think this rationale is correct, at least in the context of the Java Collections Framework. The contract of Deque doesn't explicitly mention that implementors will never ever be able to add/remove/check elements at any given index. It just says that a Deque is:
A linear collection that supports element insertion and removal at both ends.
And it also says that:
This interface defines methods to access the elements at both ends of the deque.
(Emphasis mine).
A few paragraphs later, it does explicitly say that:
Unlike the List interface, this interface does not provide support for indexed access to elements.
(Emphasis mine again).
The key part here is does not provide support. It never forbids implementors to access elements via indexes. It's just that indexed access is not supported through the Deque interface.
Think of my example above: why would a BloodDrinker disallow its implementors to drink something other than blood, i.e. water? Or why would a FlyingInsect disallow its implementors to move in a way different than flying, i.e. walking?
Bottom line, an implementation can adhere to as many contracts as it wishes, as long as these contracts don't contradict each other. And as it's worded in Java (a very careful and subtle wording, I must admit), Deque's contract doesn't contradict List's contract, so there can perfectly exist a class that implements both interfaces, and this happens to be LinkedList.

You are starting from a weak premise:
I was never taught that queue can be a list.
Let us go back to the basics. So what are data structures anyway? Here is how CLSR approaches that question1:
...Whereas mathematical sets are unchanging, the sets manipulated by
algorithms can grow, shrink, or otherwise change over time.
Mathematically, data structures are just sets; dynamic sets. In that sense, a queue can be a list. In fact, there is a problem in CLSR (10.2-3) that explicitly asks you to implement a queue by using a linked list.
On the other hand, object-oriented programming is a paradigm that helps programmers solve problems by adhering to a certain philosophy about the problem and the data. Objects, interfaces, and contracts are all part of this philosophy. Using this paradigm helps us implement the abstract concept of dynamic sets. However, it comes with its own baggage, one of them being the very problem asked about here.
So if you are complaining that the data structures in Java standard library do not strictly adhere to the conventions defined for elementary data structures, you are right. In fact, we do not even need to look further than java.util.Stack to see this2. You are also allowed to roll out your own implementation in any way you want and use them instead of standard library collections.
But to argue that Java, or its standard library for that matter, is broken or ill-done - an extraoridnary claim- you need to be very specific about the use case and clearly demonstrate how the alleged flaw in the library prevents you from achieving the design goals.
1 Introduction to Chapter III, p220
2 Sedgewick and Wayne call java.util.Stack a "wide interface"(p 160) because it allows random access to stack elements; something a stack -as defined in elementary data structures- is not supposed to be capable of.

You are entirely correct in this and not missing the point at all. Java simply made a trade-off between correctness and ease. Making it implement both interfaces was the easy thing to do and the one that was the most useful for developers.
What subtyping means
Correct (sound) subtyping requires substitution to work which requires according to the LSP:
Invariants of the supertype must be preserved in a subtype.
When we say in type theory "A LinkedList is a List and a Queue" we are actually saying that a LinkedList is both a list and a queue at the same time and not that a LinkedList can be thought of as either a list or a queue.
There is a violated invariant of a queue type here (that you cannot modify elements in its middle) so it is incorrect subtyping.
The actual argument that should be had is "whether or not a queue requires that elements can't be modified in the middle or only that they can be modified in the ends in FIFO".
One might argue that the invariants of a Queue are only that you can use it in a FIFO matter and not that you must. That is not the common interpertation of a queue.

Using a stack as a Queue in Java

I need to process a tree in different orders, let's say BFS and DFS. Both is easy by using a queue or a stack, however, I'm missing a proper interface in Java allowing to do something like
QueueOrStack<N> pending = ...
while (!pending.isEmpty()) {
N node = pending.poll(); // <----- this is the problem
pending.addAll(node.children());
process(node);
}
There's no real problem, I can encapsulate an ArrayList into something implementing Queue1, however I'd bet I'm overlooking something in the Java Collection Framework. Or is it really missing?
__
1 or use a newest-first comparator with a PriorityQueue, which is probably a dumb idea

There is such a structure.
It is called ArrayDeque -> http://docs.oracle.com/javase/6/docs/api/java/util/ArrayDeque.html

FIFO based Queue implementations?

I need a simple FIFO implemented queue for storing a bunch of ints (I don't mind much if it is generics implementation).
Anything already baked for me in java.util or Trove/Guava library?

Yeah. Queue
LinkedList being the most trivial concrete implementation.

Here is example code for usage of java's built-in FIFO queue:
public static void main(String[] args) {
Queue<Integer> myQ = new LinkedList<Integer>();
myQ.add(1);
myQ.add(6);
myQ.add(3);
System.out.println(myQ); // 1 6 3
int first = myQ.poll(); // retrieve and remove the first element
System.out.println(first); // 1
System.out.println(myQ); // 6 3
}

ArrayDeque is probably the fastest object-based queue in the JDK; Trove has the TIntQueue interface, but I don't know where its implementations live.

A LinkedList can be used as a Queue - but you need to use it right. Here is an example code :
#Test
public void testQueue() {
LinkedList<Integer> queue = new LinkedList<>();
queue.add(1);
queue.add(2);
System.out.println(queue.pop());
System.out.println(queue.pop());
}
Output :
1
2
Remember, if you use push instead of add ( which you will very likely do intuitively ), this will add element at the front of the list, making it behave like a stack.
So this is a Queue only if used in conjunction with add.
Try this :
#Test
public void testQueue() {
LinkedList<Integer> queue = new LinkedList<>();
queue.push(1);
queue.push(2);
System.out.println(queue.pop());
System.out.println(queue.pop());
}
Output :
2
1

Queue is an interface that extends Collection in Java. It has all the functions needed to support FIFO architecture.
For concrete implementation you may use LinkedList. LinkedList implements Deque which in turn implements Queue. All of these are a part of java.util package.
For details about method with sample example you can refer FIFO based Queue implementation in Java.
PS: Above link goes to my personal blog that has additional details on this.

Equivalent of std::vector in Java?

What would be the closest thing to a std::vector in Java? By this I mean, a class which can take in T into its constructor and then pushBack, popBack() and that is stored in continuous memory (not linked list).
Thanks

ArrayList
Everything's stored in array ("contiguous memory") internally, although operation names are a bit different.
A bit more about list implementations in Java
And about generics
edit
Helper Method also mentioned useful class in his answer (although not exactly equivalent to C++ Vector).

That would probably be ArrayDeque, if you need Stack functionality.
Do not use the Stack class as other here suggest.

Is ArrayList what you're looking for?
ArrayList l = new ArrayList<String>();
So you can have a list of anything (defined between the <>).

You're probably looking for the ArrayDeque which supports push/pop style access from both ends of the list efficiently.
Avoid Stack and Vector - these are synchronized, which implies generally pointless overhead.
ArrayList is also fine; however, you'd need to implement your own (trivial) pop method since it is not provided by the class itself. ArrayList does permit indexed access, which ArrayDeque lacks.

You can use an ArrayDeque, it doesn't support random access but support Deque (double ended queue) methods

Java has Stack which supports push and pop. (http://download.oracle.com/javase/6/docs/api/java/util/Stack.html)

How about simply the Vector class?
http://download-llnw.oracle.com/javase/6/docs/api/java/util/Vector.html

What you need is exactly an java.util.ArrayList<T> You can check the documentation in http://docs.oracle.com/javase/7/docs/api/java/util/ArrayList.html
Basically is a List implemented with an Array where the references live in a continuous chunk of memory.
I recommend to use in combination with a interface variable like this: List<String> stringList = new ArrayList<String>();
so if you decide, you can change the implementation to java.util.LinkedList<T> or another one.

i think it is the LinkedList
vector (c++) <===========> linkedlist(java)
v.front() <===========> l.peekFirst()
v.back() <===========> l.peekLast()
v.push_back(x) <===========> l.add(x)
v.pop_back() <===========> l.pollLast()

How to pop items from a collection in Java?

Is there a method in JDK or apache commons to "pop" a list of elements from a java.util.List? I mean, remove the list of elements and return it, like this method:
public Collection pop(Collection elementsToPop, Collection elements) {
Collection popped = new ArrayList();
for (Object object : elementsToPop) {
if (elements.contains(object)) {
elements.remove(object);
popped.add(object);
}
}
return popped;
}

If you're looking for a stack-like structure I suggest accepting a Deque (LinkedList is the most common implementation) instead of a Collection.
If you don't actually need to treat it as a stack, just get an iterator from the Collection and use the remove() method:
for (Iterator<SomeType> it = elements.iterator(); it.hasNext(); ) {
SomeType e = it.next();
it.remove();
popped.add(e);
}
Do note that remove is an optional operation, and some implementations may throw an UnsupportedOperationException (for example, the iterator returned by a Collection from Collections.unmodifiable...() will).
Edit: After looking more closely at your question, I think you just need this:
elements.removeAll(elementsToRemove);
If your main point is you need to know exactly which elements were actually popped, I think you're stuck with your original code.

There is no such method in the standard JDK-provided methods. Apache Commons provides the ListUtils.subtract() method.
Edit: As other answerers have noted, your use of the term pop is nonstandard. Usually,
The pop operation removes an item from the top of [a stack]
Wikipedia has a nice description of stacks.

I guess no, because you definition of 'pop' operation is highly non-standard. Usually it takes no arguments (except collection itself) and returns and removes the top-most one.
But once you noted apache commons, this would achieve the same effect as your code.
Collection result = CollectionUtils.intersection(a, b);
a.removeAll(b);
edit
http://commons.apache.org/collections/api-release/index.html

Linked List provides the functionality as you require, provides a push and pop method.
Refer to the documentation as provided:

There isn't a method exactly like what you are asking for, but it looks like you are already pretty close with your code.
Some suggestions:
Consider using removeAll(object) instead of remove(object) if elements is an arbitrary collection since you may need to remove duplicates e.g. if elements is a list.
contains() is slow for some collection types (e.g. lists) since it needs to traverse the entire data structure. Given that this is in your inner loop you are at risk of O(n^2) performance issues. If you can make the algorithm work with a HashSet or HashMap then contains() will by O(1) and your algorithm will be much more efficient.