ReversibleCollection proposal

Stuart Marks stuart.marks at
Wed Apr 28 00:04:22 UTC 2021

On 4/27/21 2:25 AM, Peter Levart wrote:
> Right, I'm persuaded. Now if only the problems of transition to the usage of new 
> type that Remi is worried about were mild enough. Source (in)compatibility is not 
> that important if workarounds exist that are also backwards source compatible so 
> that the same codebase can be compiled with different JDKs. Binary compatibility is 
> important. And I guess there is a variant of the proposal that includes 
> ReversibleCollection and ReversibleSet and is binary compatible.

Yes, the source incompatibilities with the types seem to involve type inference 
(e.g., use of var choosing differently based on new types in the library) so it 
should be possible to make minor source code changes to adjust or override the type 
that's inferred.

On binary compatibility, that comes mostly from the newly introduced methods 
(reversed, addFirst etc.) and from adding covariant overrides to LinkedHashSet. I 
guess the "variant" you mention is adding new methods with the new return types 
(e.g., reversibleEntrySet) instead of covariant overrides. Or was it something else?

> Now just some of my thoughts about the proposal:
> - SortedSet.addFirst/.addLast - I think an operation that would be used in 
> situations like: "I know this element should always be greater than any existing 
> element in the set and I will push it to the end which should also verify my 
> assumption" is a perfectly valid operation. So those methods throwing 
> IllegalStateException in case the invariant can't be kept seem perfectly fine to me.
> - ReversibleCollection.addFirst/.addLast are specified to have void return type. 
> This works for List and Deque which always add element and so have no information to 
> return. OTOH Collection.add is specified to return boolean to indicate whether 
> collection was modified or not, but Set modifies the specification of that method a 
> bit to be: return false or true when Set already contained an element equal to the 
> parameter or not. So ReversibleCollection.addFirst/.addLast could play the same 
> trick. for List(s) and Deque(s) it would always return true, but for 
> ReversibleSet(s) it would return true only if the set didn't contain an element 
> equal to the parameter, so re-positioning of equal element would return false 
> although the collection was modified as a result.

Anthony Vanelverdinghe replied to both of these points so I'll follow up in a reply 
to his message.

> - Perhaps unrelated to this proposal, but just for completeness, existing Collection 
> interface could be extended with methods like: getAny() and removeAny().

Yes, I think there's something going on here, but the issues lead off in a different 
direction, which I think would be a distraction from ReversibleCollection. So I'd 
like to keep this as a separate topic. (But it's not a prohibition against talking 
about them.) Indeed, I see that Henri Tremblay has coincidentally (?) raised a 
similar topic, so I'll reply further to his message.


More information about the core-libs-dev mailing list