The Collections Framework

Why this matters

• The framework has dozens of classes, and picking by habit rather than by shape is how an application ends up doing linear scans where a hash lookup would do.
• Interviews reliably ask you to justify a choice, and "I always use ArrayList" is not a justification.
• Knowing the interface you should declare — as opposed to the class you instantiate — is what keeps code swappable.

The shape of the framework

Two roots, not one. Collection covers things holding single elements; Map holds pairs and is deliberately separate because its operations have a different shape.

Choosing, in four questions

Cost at a glance

The operation that dominates your code is the one to optimise for.

Declare the interface, instantiate the class

// Good: callers depend on the capability, and you can change your mind
List<String> names = new ArrayList<>();
Map<String, Integer> counts = new HashMap<>();
Set<String> seen = new LinkedHashSet<>();

// Avoid: the concrete type leaks into every signature that touches it
ArrayList<String> rigid = new ArrayList<>();

Declaring List means switching to a LinkedList, or to an immutable List.of(...), is a one-line change. Declaring ArrayList spreads that decision across every method signature it reaches.

Immutable and unmodifiable collections

Three things that are easy to confuse.

// Immutable factories — Java 9+. Reject nulls, no duplicates for Set and Map keys.
List<String> fixed = List.of("a", "b", "c");
Set<Integer> ids = Set.of(1, 2, 3);
Map<String, Integer> ages = Map.of("Ana", 30, "Bo", 25);

// A snapshot copy: independent of the source from this moment on
List<String> snapshot = List.copyOf(mutableSource);

// A view: read-only through this reference, but changes to the source show through
List<String> view = Collections.unmodifiableList(mutableSource);

Null tolerance differs

This catches people out because the behaviour is inconsistent across implementations.

Methods on the interfaces themselves

Java 8 added default methods that remove most explicit loops.

List<String> names = new ArrayList<>(List.of("ana", "bo", "carl"));

names.removeIf(name -> name.length() < 3);          // safe removal, no iterator needed
names.replaceAll(String::toUpperCase);               // in-place transform
names.forEach(System.out::println);

Map<String, Integer> counts = new HashMap<>();
counts.merge("ana", 1, Integer::sum);                // insert 1, or add to the existing value
counts.computeIfAbsent("bo", key -> expensive(key)); // compute only when missing
counts.getOrDefault("carl", 0);                      // no null check needed
counts.putIfAbsent("dee", 5);
counts.forEach((key, value) -> System.out.println(key + "=" + value));

merge and computeIfAbsent deserve special note: they replace the check-then-act pattern that is both verbose and wrong under concurrency.

Legacy classes to avoid

These remain in the JDK only for backward compatibility. Seeing one in modern code is a signal that the code is old or was copied from something old.

Common misreadings

• "Map extends Collection." It does not. The two hierarchies are separate by design.
• "Collections and Collection are the same." Collection is the interface; Collections is a utility class of static helpers.
• "List.of(...) returns an ArrayList." It returns a compact immutable implementation that throws on modification.
• "LinkedList is faster for insertions." Only at a position you already hold. Reaching the middle is O(n), and ArrayDeque beats it at both ends.
• "Every collection accepts null." TreeSet, TreeMap, ConcurrentHashMap and all the of(...) factories do not.
• "Vector is the thread-safe list to use." Its per-method locking neither performs well nor makes compound operations safe.