RFR: 8266571: Sequenced Collections [v4]

[Chen Liang]

On Wed, 29 Mar 2023 21:18:04 GMT, Rémi Forax <forax at openjdk.org> wrote:

>> 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).

So your model would be like:

public interface Collection<T> ... {
    ...
    default Collection<T> reversed() {...} // - can dump to array
    default void addLast() {...} // or addFirst - no reliable impl
    default boolean removeLast() {...} // or removeFirst - no reliable impl
    default T getLast() {...} // or getFirst - can dump to array
}

I don't think `reversed()` is the problem here; `addLast` `removeLast` cannot be implemented from the existing Collection methods without risking contract violations, so I don't recommend leaving them as default methods. I still think SequencedCollection should exist for its specification of add/removeLast and improved performance of getLast.

That said, it is true that SequencedCollection as an interface itself has less merit as unmodifiable/immutable collections. It will only work as a marker indicating the contract that an encounter sequence is defined.

For libraries, they can use version-specific class files in META-INF; to un-sequence a collection implementation should be quite simple, as nuking the bridge `reversed` returning `SequencedCollection` and the `SequencedCollection` symbol from interface lists. This can be done with a simple classfile transformer.

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

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