How Is the Collections Framework Organized?

The framework is built around a small number of interfaces, with the implementation classes behind them. Two roots matter: Collection, which is extended by List, Set and Queue, and Map, which stands apart because it maps keys to values rather than holding elements.

The core interfaces and what they promise. List is ordered and allows duplicates — you can get an element by index. Set is a collection with no duplicate elements, so it models uniqueness. SortedSet and NavigableSet add ordering and navigation operations. Queue and Deque model a FIFO or LIFO collection. Map is a key-value dictionary, and its sorted variant SortedMap keeps its keys in order.

Behind those sit the implementations you use every day: ArrayList and LinkedList for lists, HashSet, LinkedHashSet and TreeSet for sets, HashMap, LinkedHashMap and TreeMap for maps, and ArrayDeque and PriorityQueue for queues. The interface is the contract, the class is one implementation of it, and you should depend on the interface.

import java.util.ArrayDeque;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.LinkedHashMap;
import java.util.LinkedHashSet;
import java.util.List;
import java.util.Map;
import java.util.Queue;
import java.util.Set;

public class Main {
    public static void main(String[] args) {
        // List: ordered, duplicates allowed.
        List<String> list = new ArrayList<>(Arrays.asList("b", "a", "b"));
        System.out.println("list  : " + list);

        // Set: unique elements.
        Set<String> set = new LinkedHashSet<>(Arrays.asList("b", "a", "b"));
        System.out.println("set   : " + set);

        // Map: key to value.
        Map<String, Integer> map = new LinkedHashMap<>();
        map.put("a", 1);
        map.put("b", 2);
        System.out.println("map   : " + map);

        // Queue: first in, first out.
        Queue<String> queue = new ArrayDeque<>(Arrays.asList("x", "y"));
        System.out.println("queue : " + queue);
    }
}

The output shows the defining behaviour of each. The list keeps all three elements including the duplicate b. The set drops the duplicate. The map stores two key-value pairs. And the queue is ready to be polled in insertion order.

List is an ordered collection that allows duplicates and supports positional access. You can ask for the third element, insert at an index, and find the index of a value. Duplicates are meaningful, so a list of a student's course enrolments would be a List.

Set is a collection of unique elements. Adding an element that is already present changes nothing, and that is the entire point — it models mathematical sets and gives you O(1) membership testing. The interface does not promise an order, but the implementations differ: HashSet makes no order guarantee, LinkedHashSet preserves insertion order, and TreeSet keeps the elements sorted.

Map is not a Collection at all — it does not extend Collection, and you cannot iterate over a map directly. It maps unique keys to values, each key appearing at most once. The key's hashCode and equals determine identity, which is why Strings make good keys and mutable objects make terrible ones.

Queue is a collection designed for processing elements in order, normally first in first out. Its poll and peek methods remove or inspect the head without throwing when the queue is empty. The Deque interface extends it to allow insertion and removal at both ends, which covers the stack use case as well.

The selection questions to ask yourself are short: do I need order? Do I need duplicates? Do I need to look things up by key? Will I add and remove from both ends? The answers point at the interface.

Default methods let an interface provide a method body, so implementations inherit it and only override it when they need something different. On Collection, the important ones are removeIf, stream, forEach and removeAll and retainAll, and they solve a specific problem: the Collections Framework was designed in 1997, long before lambdas, so several of its methods took awkward functional interfaces such as Predicate that you could only pass as an anonymous class.

The practical benefit is that most of the framework now works naturally with method references and lambdas. removeIf replaced the need to use an Iterator and call remove manually, and it is also the safe way to delete elements during iteration because the collection handles its own modification counter. stream gave every collection the whole Stream API without the framework having to know anything about streams in advance.

import java.util.ArrayList;
import java.util.List;

public class Main {
    public static void main(String[] args) {
        List<String> words = new ArrayList<>(List.of("apple", "fig", "banana", "date"));

        // removeIf is a default method on Collection.
        words.removeIf(w -> w.length() > 4);
        System.out.println("after removeIf : " + words);

        // forEach is a default method too.
        words.forEach(w -> System.out.println("word: " + w));

        // stream() opens up the whole Stream API.
        System.out.println("upper : " + words.stream().map(String::toUpperCase).collect(java.util.stream.Collectors.toList()));
    }
}

The output shows all three in use. The list is filtered down to the two short words, each is printed in turn, and the stream pipeline produces a new list of uppercase versions without mutating the original.

There is a caveat about default methods and inheritance that comes up in interviews. If a class inherits a default method from one interface and a class of the same method from a superclass, the class wins — that is the rule that keeps existing code working. If two unrelated interfaces provide the same default method, the implementing class has to override it and resolve the conflict. The one design warning is that default methods should be small and genuinely universal, because a default method that grows into a hundred lines inside an interface is a design smell that the language cannot warn you about.