The SequencedMap interface defines three new view collection methods sequencedKeySet(), sequencedValues(), and sequencedEntrySet(). These methods return a SequencedCollection (or SequencedSet, which is a subtype of SequencedCollection). The @implSpec clause of these methods specifies the behavior of a few particular methods and then says "Each of its other methods calls the corresponding method of the keySet view of this map." (Or values view or entrySet view, respectively.)

The problem is that the SequencedCollection methods addFirst, addLast, getFirst, getLast, removeFirst, and removeLast methods are not present on the (non-sequenced) keySet, values, and entrySet views of a map. Thus they have no "corresponding" method.

In fact these sequenced view implementations inherit the corresponding default methods from the SequencedCollection interface, which are implemented in terms of reversed() and iterator() and Iterator methods. Things actually work, but they don't comply with the @implSpec clauses, and in fact this is a fairly roundabout way of implementing these methods.

The addFirst and addLast methods should simply throw UnsupportedOperationException. The getFirst and removeFirst methods should be reimplemented in terms of firstEntry and pollFirstEntry (respectively, -last). And the @implSpec clauses should be updated to specify this.

This change is functionally equivalent but the change in behavior may be visible to applications. The main paths go through different methods, so subclasses may observe different behavior. The Map.Entry instances returned by getFirst and getLast on the entrySet view originate differently. Previously they came from an iterator, and with this change they will come from firstEntry/lastEntry. In the former case this will generally permit the underlying map to be modified by calling the setValue() method on the Entry, whereas with this change they are specified to return unmodifiable entries.