skip to content

What are Sequenced Collections (JEP 431, Java 21), and what problem do they solve?

level: juniorimportance: must knowfreq 62%

answer

  1. JEP 431, Java 21
  2. Unify defined encounter order
  3. first/last + reversed() view
  4. Retrofitted onto List/Deque/LinkedHash*/Sorted*
  5. Fixes inconsistent first()/get(0)/peekFirst()

basics

~20 s

They are new interfaces (SequencedCollection, SequencedSet, SequencedMap) added in Java 21 that give collections with a defined order a uniform way to access and add elements at the front and back, plus a reversed() view.

solid answer

~40 s

Sequenced Collections (JEP 431, Java 21) add three interfaces: SequencedCollection, SequencedSet, and SequencedMap. Before them, Java had many collections with a well-defined encounter order (List, Deque, LinkedHashSet, LinkedHashMap, SortedSet, SortedMap) but no common type expressing that order and no uniform first/last operations. For example, a List's first element is list.get(0) but a Deque's is deque.peekFirst() and a SortedSet's is set.first() — three different method names for the same idea, and there was no clean way to get the last element of a LinkedHashSet at all. The new interfaces unify this with addFirst/addLast, getFirst/getLast, removeFirst/removeLast, and a reversed() view that exposes the same elements in opposite order. Existing types were retrofitted to implement them, so you gain these methods without changing your code.

go deeper

for a junior

Knows the three interface names, that they arrived in Java 21, and that they add first/last access and reversed().

for a middle

Can explain the inconsistency they fix (get(0) vs first() vs peekFirst()) and list which existing types were retrofitted.

for a senior

Articulates the design rationale (unifying encounter order without new classes), the view semantics of reversed(), and the exceptions/edge cases.

for a principal

Discusses backward-compatibility strategy of retrofitting interfaces onto a 25-year-old hierarchy, the immutability/UOE implications, and when to expose SequencedCollection in an API contract.

## The problem A *collection* in Java is an object that holds a group of elements (a `List` of names, a `Set` of unique ids, a `Map` of key→value pairs). Some collections have an **encounter order**: a well-defined order in which iteration visits the elements. A `List` (like `ArrayList`) keeps insertion order and is indexable; a `Deque` (double-ended queue, like `ArrayDeque`) has a head and a tail; a `LinkedHashSet`/`LinkedHashMap` remembers insertion order; a `SortedSet`/`SortedMap` (`TreeSet`/`TreeMap`) orders by a comparator. Before Java 21, there was **no shared interface** that simply said "this collection has a defined order, and here is how you touch its ends." That caused three pains: 1. **Inconsistent method names for the same idea.** To get the first element: `list.get(0)`, `deque.getFirst()`, `sortedSet.first()`, `linkedHashSet.iterator().next()`. Four collections, four idioms. 2. **Missing operations.** A `LinkedHashSet` has a clear *last* element, but there was no direct `getLast()` — you had to iterate to the end or build a reversed copy. 3. **No uniform reverse view.** Iterating back-to-front meant different tricks per type (`descendingIterator()`, `descendingSet()`, manual index loops), and some types offered nothing. ## The solution: JEP 431 JEP (Java Enhancement Proposal) 431, delivered in **Java 21 (September 2023)**, introduced three new interfaces in `java.util`: - **`SequencedCollection<E>`** — a collection with a defined encounter order and end-access methods. - **`SequencedSet<E>`** — a `SequencedCollection` that is also a `Set` (no duplicates). - **`SequencedMap<K,V>`** — a `Map` with a defined order over its entries. The common methods on `SequencedCollection` are: - `void addFirst(E)` / `void addLast(E)` — insert at the front / back. - `E getFirst()` / `E getLast()` — read the front / back element (throws `NoSuchElementException` if empty). - `E removeFirst()` / `E removeLast()` — remove and return the front / back element. - `SequencedCollection<E> reversed()` — a **view** (not a copy) that presents the same elements in opposite order. ## Why it matters It is a small but real ergonomics win: one mental model and one set of method names for "ordered collection" across the JDK, plus the previously awkward operations (last element of a `LinkedHashSet`, reverse iteration of a `List`) become trivial. Because existing types were *retrofitted* to implement the new interfaces, you get the methods for free on `ArrayList`, `LinkedList`, `ArrayDeque`, `LinkedHashSet`, `TreeSet`, `LinkedHashMap`, `TreeMap`, and more, with no source changes required.

  • Why couldn't this just be solved by adding methods to List?
    Because the need spans more than List — Deque, LinkedHashSet, LinkedHashMap, and Sorted* all have a defined order. A shared set of interfaces lets one API cover all of them and lets you write code against 'any ordered collection.'
  • Name one operation that was awkward before Java 21.
    Getting the last element of a LinkedHashSet: there was no getLast(), so you iterated to the end or copied into a list/array first.

saying these in an interview costs you the question

  • Claiming it adds a new concrete collection class — it only adds interfaces and retrofits existing types
  • Saying every collection now has order — HashSet/HashMap are unordered and are NOT sequenced
  • Confusing it with Stream ordering or with making collections sorted
  • Thinking reversed() copies the data rather than returning a live view

context

resolving links…