skip to content

What methods does SequencedMap add, and what do putFirst/putLast do?

level: middleimportance: should knowfreq 38%

answer

  1. firstEntry/lastEntry (null if empty)
  2. pollFirstEntry/pollLastEntry remove+return
  3. putFirst/putLast insert AND reposition the key
  4. reversed() + sequencedKeySet/values/entrySet
  5. TreeMap putFirst/putLast → UnsupportedOperationException

basics

~20 s

SequencedMap adds firstEntry/lastEntry and pollFirstEntry/pollLastEntry to read or remove the end entries, putFirst/putLast to insert at the front or back, reversed() for a reverse-order view, and sequencedKeySet/values/entrySet views. putFirst/putLast set a mapping and move that key to the chosen end (for insertion-ordered maps).

solid answer

~40 s

`SequencedMap<K,V>` extends `Map` with end-aware operations over its entries: `firstEntry()`/`lastEntry()` return the first/last `Map.Entry` (or null if empty); `pollFirstEntry()`/`pollLastEntry()` remove and return them; `putFirst(k,v)`/`putLast(k,v)` insert or update a mapping and position that key at the front/back; and `reversed()` gives a reverse-ordered `SequencedMap` view. It also offers sequenced views: `sequencedKeySet()`, `sequencedValues()`, `sequencedEntrySet()`. For a `LinkedHashMap`, `putFirst`/`putLast` are the headline feature: they not only set the value but also **re-position** an existing key to the chosen end of the encounter order — something previously impossible without rebuilding the map. For `SortedMap`/`NavigableMap`, position is comparator-driven, so `putFirst`/`putLast` throw `UnsupportedOperationException`, while the read/poll/reversed operations work against the comparator order.

go deeper

for a junior

Knows SequencedMap adds first/last entry access and a way to put at the front or back.

for a middle

Lists the methods and explains that putFirst/putLast also reposition the key in a LinkedHashMap.

for a senior

Notes the null-on-empty vs throw-on-empty distinction, the sorted-map UOE for putFirst/putLast, and the sequenced view accessors.

for a principal

Reasons about ordering semantics, overlap with NavigableMap, and when SequencedMap.putFirst replaces remove+reinsert idioms (e.g. recency ordering) in API design.

## Why SequencedMap is separate from SequencedCollection A `Map` is not a `Collection` in Java's hierarchy (it maps keys to values rather than holding a flat sequence), so it gets its **own** sequenced interface, `SequencedMap<K,V>`, that mirrors the same first/last/reverse ideas but in entry terms. ## The methods - **`Map.Entry<K,V> firstEntry()` / `lastEntry()`** — return the first/last entry in encounter order, or `null` if the map is empty. (Note: returns `null`, unlike `SequencedCollection.getFirst()` which throws on empty.) - **`Map.Entry<K,V> pollFirstEntry()` / `pollLastEntry()`** — remove and return the first/last entry, or `null` if empty. - **`V putFirst(K, V)` / `V putLast(K, V)`** — insert the mapping (or update an existing one) and place that key at the **front** / **back** of the order. Returns the previous value for that key, or null. - **`SequencedMap<K,V> reversed()`** — a live reverse-order view of the whole map. - **`SequencedSet<K> sequencedKeySet()`**, **`SequencedCollection<V> sequencedValues()`**, **`SequencedSet<Map.Entry<K,V>> sequencedEntrySet()`** — sequenced views of keys/values/entries (so you can call getFirst/reversed on the key set, etc.). ## What putFirst / putLast actually do (the key insight) For an insertion-ordered map like **`LinkedHashMap`**, the order is the order keys were first inserted. `putFirst(k,v)`: 1. Sets `k → v` (inserting if absent, updating the value if present). 2. **Moves `k` to the front** of the encounter order. Before Java 21, a plain `put` on an existing key updated the value but did **not** change its position; reordering required removing and re-inserting, or rebuilding the map. `putFirst`/`putLast` make front/back repositioning a first-class one-call operation — handy for building an LRU-ish ordering or a "most-recent-first" list. ## Sorted maps: position is not yours to set For `SortedMap`/`NavigableMap` (`TreeMap`), entry position is dictated by the comparator. So `putFirst`/`putLast` throw **`UnsupportedOperationException`** — you can't force a key to an end that contradicts the sort. The read and remove ends (`firstEntry`, `lastEntry`, `pollFirstEntry`, `pollLastEntry`, `reversed`) all work and report the comparator-defined ends (these largely overlap `NavigableMap`'s pre-existing `firstEntry`/`lastEntry`/`pollFirstEntry`/`pollLastEntry`). ## Null-on-empty vs throw-on-empty A subtle consistency note: the *entry* readers (`firstEntry`/`lastEntry`) and *pollers* return **`null`** when empty, matching `NavigableMap` tradition — whereas `SequencedCollection.getFirst()`/`getLast()` **throw** `NoSuchElementException`. Don't assume both families behave the same on empty.

  • On a LinkedHashMap that already contains key 'a', what does putLast("a", v) do?
    It updates a's value to v and moves 'a' to the back of the encounter order; it returns the previous value of 'a'.
  • Why do firstEntry() and getFirst() differ on an empty container?
    firstEntry() follows the NavigableMap convention of returning null when empty, while SequencedCollection.getFirst() throws NoSuchElementException. They were designed to match their respective families.

saying these in an interview costs you the question

  • Thinking putFirst only sets the value — it also moves the key to the front
  • Assuming firstEntry throws on an empty map — it returns null
  • Expecting putFirst/putLast to work on TreeMap — they throw UOE
  • Treating SequencedMap as a Collection (Map is not a Collection)

context

resolving links…