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