RFR: 8266571: Sequenced Collections

Stuart Marks smarks at openjdk.org
Mon Mar 20 23:45:08 UTC 2023


On Wed, 5 Oct 2022 15:15:05 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/SequencedCollection.java line 93:
>> 
>>> 91:      * underlying collection. Changes to the underlying collection might or might not be visible
>>> 92:      * in this reversed view, depending upon the implementation.
>>> 93:      *
>> 
>> @stuart-marks Perhaps an opportunity to spec it so that x == x.reversed().reversed() (i.e. unwrap on double-reverse)?
>
> @stuart-marks What are examples of cases where it wouldn't be reasonable: https://github.com/openjdk/jdk/pull/7387/files#diff-2b261a88d9ed30893d24186a36ef500d284d82e8f345591fc6c44ed5ae15da4fR161 ?

I had to uncomment that line to figure out what broke. :-) Turns out `TreeSet.reversed().reversed()` doesn't return the original TreeSet. This is because `descendingSet().descendingSet()` doesn't unwrap, and neither does TreeMap's `descendingMap().descendingMap()`. I don't know what this wasn't done in the first place. Nonetheless, since unwrapping isn't done in the underlying implementation, it doesn't seem reasonable for the specification to require it be done. Furthermore this enables `reversed()` to be implemented as a default method that simply delegates to the respective `descending*()` method.

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

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


More information about the core-libs-dev mailing list