Introduction

In modern Java, Deque is usually preferred over Stack for LIFO behavior. The reason is not that stacks stopped being useful, but that java.util.Stack is a legacy class with awkward inheritance and synchronization behavior, while Deque implementations such as ArrayDeque provide a cleaner and faster stack API.

Core Sections

Stack is a legacy class

Stack extends Vector, which means it inherits a large API that has little to do with stack semantics. That inheritance leaks operations such as indexed insertion and random access into a type that is supposed to represent a strict last-in, first-out structure.

By contrast, Deque is an interface built around end-oriented operations. When you use it as a stack, the intent is clear and the exposed operations are closer to what you actually need.

1Deque<String> stack = new ArrayDeque<>();
2stack.push("first");
3stack.push("second");
4System.out.println(stack.pop());
5System.out.println(stack.peek());

That code is both idiomatic and efficient.

Deque gives the same stack operations

A common misconception is that switching to Deque means giving up stack-style methods. You do not. Deque has push, pop, and peek, so the transition is straightforward.

1Deque<Integer> values = new ArrayDeque<>();
2values.push(10);
3values.push(20);
4values.push(30);
5
6while (!values.isEmpty()) {
7    System.out.println(values.pop());
8}

If all you need is LIFO behavior, this is the direct replacement for most Stack use cases.

ArrayDeque is usually the right implementation

For an in-memory stack, ArrayDeque is normally the best default. It avoids the legacy synchronization overhead of Stack and performs very well for push and pop operations at the ends.

LinkedList also implements Deque, but it is rarely the best default stack because it uses a node-based structure with different allocation behavior and generally worse cache locality.

The practical Java rule is:

• use Deque as the variable type
• use ArrayDeque as the usual implementation

Deque is more flexible without being confusing

Another advantage is that the same type can act as a queue when needed. That does not mean every stack should suddenly become a queue, but it gives you a more general abstraction when the algorithm evolves.

1Deque<String> work = new ArrayDeque<>();
2work.addLast("a");
3work.addLast("b");
4System.out.println(work.removeFirst());

This flexibility is useful in parsers, graph algorithms, and undo-style features where the data access pattern may shift during refactoring.

When Stack might still appear

You will still see Stack in older codebases, tutorials, and interview answers. It works, and there is no emergency need to delete it from a stable system just for style reasons. But when writing new code, Deque is the API most Java developers expect.

One caveat is thread safety. ArrayDeque is not synchronized. If multiple threads need coordinated access, you need external synchronization or a different concurrent data structure. That is a concurrency question, not a reason to go back to Stack by default.

Common Pitfalls

• Treating Stack as the preferred modern Java stack type even though it is a legacy class built on Vector.
• Declaring the variable as ArrayDeque everywhere instead of the Deque interface, which makes later substitution less flexible.
• Using LinkedList automatically for stack behavior when ArrayDeque is usually the better default.
• Assuming Deque is harder to read even though it provides the same push, pop, and peek methods developers expect from a stack.
• Confusing the recommendation with thread safety and assuming Stack solves concurrent access without broader synchronization design.

Summary

• In modern Java, Deque is the preferred abstraction for stack behavior.
• 'Stack is legacy because it extends Vector and exposes API surface that does not fit strict stack semantics.'
• 'Deque still provides push, pop, and peek, so the migration is straightforward.'
• 'ArrayDeque is usually the best implementation for a single-threaded in-memory stack.'
• Choose concurrency primitives separately if multiple threads must share the structure.