RFR: 8266571: Sequenced Collections [v7]

[Stuart Marks]

On Wed, 19 Apr 2023 14:19:01 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Stuart Marks has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Remove unnecessary 'final' from a couple places.
>>  - Clarify ordering of Collection.addAll and Map.putAll; add links to
>>    encounter order.
>>  - Make constructors private for several reverse-ordered views.
>
> src/java.base/share/classes/java/util/SequencedMap.java line 110:
> 
>> 108:  * {@code Entry} thus obtained will update a mapping in the underlying map, or whether
>> 109:  * it will throw an exception, or whether changes to the underlying map are visible in
>> 110:  * that {@code Entry}.
> 
> These 3 paragraphs all talk about `Entry`s' connection to the map. I think that they can be reconciled by explicitly noting each way to get an entry and the conditions that apply on it. In broad strokes:
> 
>> `{@link Map.Entry}` instances can be obtained in several ways.
>> By iterating the `{@link #entrySet}` view... These entries maintain a connection...
>> By calling the `{@link #firstEntry}`... methods. These entries represent snapshots of...
>> By other means, such as from methods of views of the map (`sequencedMap.sequencedEntrySet().getFirst();`). These entries entries might or might not be connected...

Not sure what you're suggesting here. There are indeed different ways to obtain entries, but they can't be reconciled because the spec imposes different requirements (or explicitly leaves things unspecified) on entries obtained by different means.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1171710625