JDK-8307840 : SequencedMap view method specification and implementation adjustments
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util:collections
  • Affected Version: 21
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2023-05-10
  • Updated: 2023-06-13
  • Resolved: 2023-06-06
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 21
21 b26Fixed
Related Reports
Blocks :  
CSR :  
Description
Observed that SequencedMap : SequencedXXX   default methods implementation requirements  not correctly matching the behavior :

For example :
“Implementation Requirements:
The implementation in this interface returns a SequencedSet implementation that delegates all operations either to this map or to this map's Map.keySet(), except for its reversed method, which instead returns the result of calling sequencedKeySet on this map's reverse-ordered view.
 
Use case – invoking the “add” on the returned SequencedSet  
Expected –  invocation of “add” method on instance returned by Map.keySet().
Actual - java.lang.UnsupportedOperationException

Comments
Changeset: 95261908 Author: Stuart Marks <smarks@openjdk.org> Date: 2023-06-06 17:02:32 +0000 URL: https://git.openjdk.org/jdk/commit/952619086358326c2fb3fcbada654fc2edd09f07
06-06-2023

A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/14267 Date: 2023-06-01 16:18:12 +0000
01-06-2023

I'm adjusting the specification and implementing it as described in the "Alternatively" paragraph of my earlier comment. That is, the map's corresponding non-sequenced view collection is obtained each time instead of caching it at creation time.
31-05-2023

[~kganapureddy] Yes these spec changes will definitely be covered by a CSR.
11-05-2023

[~smarks] I believe these spec changes would be part of CSR ?
11-05-2023

This applies to the three SequencedMap methods that return sequenced views, namely, sequencedKeySet(), sequencedValues(), and sequencedEntrySet(). The implementation requirements for all of them should state: * a reference to the corresponding non-sequenced view of the underlying map is obtained once via the appropriate method * methods add() and addAll() throw UnsupportedOperationException * the reversed() method calls reversed() on the underlying map and then returns the result of calling sequencedX() on the reversed view * all other methods are delegated to the corresponding method of the non-sequenced view previously obtained. Alternatively, instead of obtaining a reference to the underlying view collection once and reusing it, it might be better to obtain the underlying view collection each time. Most implementations will cache and return the same object; but fetching it each time gives more flexibility to the underlying implementation. This is not only a spec change but a slight change in behavior. It should be specified though so that implementations can rely on these behaviors. This could be accomplished by changing the view field of AbstractMap.ViewCollection into an abstract view() method returning Collection<E>, removing the constructor argument, and adjusting the delegating methods' implementations.
10-05-2023