RFR 7065380 : Allow Collections.sort to sort Collections.singletonList() result
David Holmes
david.holmes at oracle.com
Mon Mar 12 23:53:08 UTC 2012
On 13/03/2012 5:08 AM, Jason Mehrens wrote:
>
>>> I'm not really confident about proposing "assertions as lint detection" rather than adding explicit checks. We wouldn't (and don't) use optional assertions for array bounds checking. This has clearly been the right choice. I'm still considering my>>feelings about whether to be hardline and suggest we add the checks to Arrays.sort
>
>
>
>>>
>>> Thoughts anyone?
>
> Add wiggle room to the throws CCE javadocs to suggest detection doesn't occur for all cases.
>
> Reading over the bug report again, the justification example is flawed. The caller only knows it is safe to call sort when the documentation for 'generate' states that the returned list is mutable. If the returned list is mutable, it is not a Collections$SingletonList. If 'generate' returns an unmodifiable list the call has to make a mutable copy. If the caller has to create a copy, the caller could perform the size check first.
>
> Close as Not a bug??
Well it's not a bug it is a RFE. :) But I agree that the example is a
little flawed in that generate() would not reasonably be able to
generate mutable lists in some cases and immutable lists in others.
I find the restriction on empty/singleton lists unnecessary, but not
sure it is worth jumping through the spec hoops to change this.
David
> Jason
More information about the core-libs-dev
mailing list