What are Sequenced Collections (JEP 431, Java 21), and what problem do they solve?
answer
- JEP 431, Java 21
- Unify defined encounter order
- first/last + reversed() view
- Retrofitted onto List/Deque/LinkedHash*/Sorted*
- Fixes inconsistent first()/get(0)/peekFirst()
basics
~20 sThey 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 sSequenced 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
Knows the three interface names, that they arrived in Java 21, and that they add first/last access and reversed().
Can explain the inconsistency they fix (get(0) vs first() vs peekFirst()) and list which existing types were retrofitted.
Articulates the design rationale (unifying encounter order without new classes), the view semantics of reversed(), and the exceptions/edge cases.
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