RFR: 8266571: Sequenced Collections [v4]
Rémi Forax
forax at openjdk.org
Wed Mar 29 21:59:08 UTC 2023
On Wed, 29 Mar 2023 20:54:15 GMT, Chen Liang <liach at openjdk.org> wrote:
>> Yes,
>> The spec says :"Changes to the underlying collection might or might not be visible in this reversed view, depending upon the implementation." so i believe the default implementation i proposed is a valid implementation
>
> In the JEP, it says:
>> Any modifications to the original collection are visible in the view.
>
> If we don't have an efficient reversed view, I don't see a point of declaring a collection sequenced; same reason for declaring a sequenced/deque vs. a full-on list with inefficient list random access operations.
The quote is from the javadoc of reversed (see above), it seems the JEP and the javadoc disagree :(
> If we don't have an efficient reversed view, I don't see a point of declaring a collection sequenced
Collections in the JDK provides more efficient implementations, this is what the code this PR does.
Providing a default implementation matters more for external libraries.
And that's why i think we do not need the interface SequencedCollection, because all these methods can be declared on Collection instead. Adding them on Collection has also the added benefit that as a user, all Clojure collections or any other implementations not in the JDK also get a good enough implementation of the method reversed().
My fear is that if we introduce all these methods on SequencedCollection instead of Collection, library implementations will never be updated to use SequencedCollection instead of Collection (because implementing SequencedCollection requires the library to work only on JDK 21+) while if reversed is declared on Collection, library maintainers will have more pressure to write an efficient implementation of reversed for their implementations (and will be able to do that without requiring the JDK 21).
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1152494872
More information about the core-libs-dev
mailing list