skip to content

Collections Static Utilities

5 roadmaps5 questions

The Collections class collects the algorithms and wrappers: sort, binarySearch, reverse, shuffle, the unmodifiable read-only views, the synchronized wrappers, and the empty and singleton factories. Interviewers focus on unmodifiable being a view, not a copy.

part ofJavaoverview, primer and where to startread it →
on this pageshow

explore

questions

5

What is the java.util.Collections class, and how does it differ from the Collection interface?

level: juniorimportance: must knowfreq 70%

answer

  1. Collection = interface, Collections = static toolbox
  2. Mirror of Arrays for plain arrays
  3. final class, private ctor, all static
  4. sort/reverse/shuffle, unmodifiable/synchronized, empty/singleton

basics

~10 s

Collection (no 's') is the interface that lists and sets implement. Collections (with 's') is a helper class full of static methods like sort, reverse, and emptyList that operate on those collections.

solid answer

~30 s

java.util.Collection is the root interface of the collections hierarchy (List, Set, Queue all extend it). java.util.Collections is a separate utility class that only holds static helper methods and constants; you never instantiate it. Its methods take a collection as an argument and do something useful: sort and binarySearch on lists, reverse and shuffle, unmodifiableList and synchronizedMap wrappers, and factories like emptyList and singletonList. The naming is a classic Java gotcha because the two are unrelated types that differ only by an 's'. Collections sits beside Arrays, which plays the same utility role for plain arrays.

go deeper

for a junior

Knows Collections is a helper class with static methods (sort, reverse) and that it is not the same as the Collection interface.

for a middle

Explains the utility-class pattern (final, private ctor, static), and names the wrapper/factory families alongside the algorithms.

for a senior

Articulates why the class exists historically (no interface default methods pre-Java 8) and contrasts it with Arrays and with Stream-based alternatives.

for a principal

Frames it as a design-pattern example, discusses migration toward List.of/Stream APIs, and the legacy/compat tradeoffs of keeping these wrappers.

## The two confusingly named types Java has two types whose names differ by a single letter, and they do completely different jobs: - **`java.util.Collection`** (singular) is an **interface** — the root of the collections type hierarchy. `List`, `Set`, and `Queue` all extend it; `ArrayList`, `HashSet`, etc. ultimately implement it. An interface defines *what operations a collection supports* (add, remove, size, iterator) without saying how. - **`java.util.Collections`** (plural) is a **utility class** — a `final` class with a `private` constructor, so you can never create an instance of it. It contains only `static` methods (and a few constants). A static method belongs to the class itself, so you call it as `Collections.sort(list)`, not on an object. The relationship is: `Collections` is a toolbox *for* working with `Collection` objects. It is the exact analogue of `java.util.Arrays`, which is the toolbox for plain arrays. ## What lives in Collections The class groups several families of helpers: 1. **Algorithms on `List`:** `sort(list)`, `sort(list, comparator)`, `binarySearch(list, key)`, `reverse(list)`, `shuffle(list)`, `swap`, `fill`, `max`, `min`, `frequency`, `rotate`. 2. **Read-only (unmodifiable) wrappers:** `unmodifiableList`, `unmodifiableSet`, `unmodifiableMap` — return a view that throws `UnsupportedOperationException` on any mutating call. 3. **Thread-safe (synchronized) wrappers:** `synchronizedList`, `synchronizedSet`, `synchronizedMap` — wrap each method in a lock. 4. **Empty / singleton factories:** `emptyList()`, `emptySet()`, `emptyMap()`, `singletonList(x)`, `singleton(x)`, `singletonMap(k,v)` — tiny immutable collections. ## Why a separate utility class at all? Before Java 8 introduced default methods, an interface could not carry implemented behavior. So shared algorithms that work on *any* `List` (like sorting) had to live somewhere external — a static utility class was the answer. `Collections` (1998, Java 1.2) is one of the oldest examples of this pattern. ## Key terms defined - **Static method:** a method called on the class, not an instance. - **Utility class:** a class that exists only to hold static helpers; not meant to be instantiated. - **Interface:** a contract of method signatures a type promises to implement. - **View / wrapper:** an object that delegates to an underlying collection rather than copying it; changes to the original are visible through the view. ## The practical takeaway When you want to *do something to* a list or set — sort it, make it read-only, get an empty one — reach for `Collections.xxx(...)`. When you want to *describe* what a parameter accepts, type it as `Collection<T>` (the interface).

  • Can you instantiate Collections?
    No. It is a final class with a private constructor; every member is static, so you only ever call Collections.xxx(...).
  • What is the array equivalent of Collections?
    java.util.Arrays — it provides Arrays.sort, Arrays.asList, Arrays.binarySearch, etc. for plain arrays.

saying these in an interview costs you the question

  • Thinking Collections is the parent interface of List/Set
  • Trying to `new Collections()`
  • Confusing Collections.sort with Stream.sorted (different APIs)

context

resolving links…

open as a page

How do Collections.sort and Collections.binarySearch work, and what are their requirements and complexity?

level: middleimportance: must knowfreq 65%

basics

~10 s

Collections.sort(list) orders a list ascending, either by the elements' natural order or by a Comparator you pass. Collections.binarySearch(list, key) finds an element quickly, but only works if the list is already sorted.

open as a page

What are the Collections.emptyList and singletonList factories, and why are they useful?

level: juniorimportance: should knowfreq 45%

basics

~10 s

Collections.emptyList() gives you a shared, immutable empty list, and singletonList(x) gives an immutable one-element list. They are handy lightweight return values when you'd otherwise create a tiny list, and they can't be modified.

open as a page

What do the Collections.synchronizedXxx wrappers provide, what are their limits, and when would you prefer the java.util.concurrent collections?

level: seniorimportance: should knowfreq 50%

basics

~20 s

Collections.synchronizedList/Map wrap a collection so each single method call is thread-safe via an internal lock. But iterating still needs you to lock manually, and a single global lock is slow under load, so concurrent collections like ConcurrentHashMap are usually better.

open as a page

What does Collections.unmodifiableList return, and how is it different from a truly immutable collection like List.of?

level: seniorimportance: should knowfreq 55%

basics

~20 s

It returns a read-only view of an existing list: you cannot add or remove through it, but the original list can still be changed and those changes show up. List.of is a separate, fully immutable copy that nobody can change.

open as a page