On Wed, 19 Apr 2023 14:19:01 GMT, Nir Lisker <nlis...@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
