The SequencedMap class specification imposes additional ordering requirements on several methods of Map:

«The bulk operations on this map, including the forEach and the replaceAll methods, operate on this map's mappings in encounter order. ... The view collections provided by the keySet, values, [and] entrySet ... methods all reflect the encounter order of this map.»

However, this stipulation is easy to miss if one is looking for the specification of one of these methods in the javadoc. These methods are inherited from Map by SequencedMap, so they'll be found at the bottom of the Method Summary table in a section called "Methods declared in interface Map". Clicking on one of these links will bring up the specification from the Map interface, which of course will say nothing about encounter order. It's thus very easy for a reader to miss the fact that SequencedMap requires these methods to respect encounter order.

A similar phenomenon occurs in some IDEs. Pointing at or autocompleting one of these methods will bring up the method specification from Map, which may cause the reader to miss the encounter order requirement.

These methods should have no-op overrides added (ones that forward the method to super) that have javadoc comments that inherit the spec from the superclass and include an additional clause about encounter order.

The SequencedMap class specification also says:

«Even though the return values of the keySet, values, and entrySet methods are not sequenced types, the elements in those view collections do reflect the encounter order of this map.»

It might be worth mentioning this in the specs of the respective methods. But it might be better to link to the corresponding sequencedX view methods which return views that not only respect encounter order, but that return sequenced types and thus afford sequence-respecting operations.