RFR 7065380 : Allow Collections.sort to sort Collections.singletonList() result
Alex Lam S.L.
alexlamsl at gmail.com
Fri Mar 2 00:02:11 UTC 2012
I fail to come up with a (common) use case where this will be enabling
- I did read the example in the bug description but wasn't quite
Having said that, a generalisation whereby Arrays.sort(a) or an
internal version of it returns a boolean indicating whether any
elements has been swapped, then based on that optionally carrying out
the set() operations might be an interesting optimisation which will
also cover this particular case of empty / singleton.
On Thu, Mar 1, 2012 at 10:33 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> +1. A no-op sort() on an emptyList or singletonList() behaves in an
> intuitive manner, IMHO. If the concern is that sort() will hide user bugs,
> well my answer would be that sort()'s job is just that: sort the collection
> -- it's not a defense mechanism for catching unrelated user bugs.
> On Thu, Mar 1, 2012 at 5:02 PM, Mike Duigou <mike.duigou at oracle.com> wrote:
>> I always read @throws declarations as "if thrown then description was the
>> cause" rather than "will be thrown if description". A minor difference in
>> interpretation that can sometimes be useful.
>> For this particular case the restriction on sort() seems to serve only to
>> blunt the usefulness of Collections.emptyList and singletonList(). I'd
>> prefer to bend the rules slightly rather than requiring developers to use
>> empty and singleton ArrayLists.
>> On Mar 1 2012, at 13:29 , Colin Decker wrote:
>> > Doesn't this break the contract of the method? It specifies that it
>> throws UnsupportedOperationException if the specified list's list-iterator
>> does not support the set operation. Its Javadoc body also states that the
>> list must be modifiable. (Though sort() already succeeds for an emptyList()
>> despite it not supporting set.) It seems to me that this just hides
>> programmer error. Anyone who passes an unmodifiable singleton list to
>> sort() is treating it as a modifiable list in their code. Rather than
>> succeeding despite that, I'd think it might be preferable for the call to
>> fail so the programmer is alerted to that error in their assumptions so
>> they can correct it before it bites them elsewhere.
>> > --
>> > Colin
>> > 5
>> > On Thu, Mar 1, 2012 at 2:40 PM, Mike Duigou <mike.duigou at oracle.com>
>> > Hello all;
>> > Currently Collections.sort() refuses to sort the lists which result from
>> calling Collections.singletonList(). This makes some sense because the
>> singleton lists are immutable but they are also alway sorted.
>> > This patch allows Collections.sort() to be used with empty and singleton
>> lists of all types. A short circuit return is provided for lists of length
>> 0 and 1 as they are already sorted.
>> > WEBREV @ http://cr.openjdk.java.net/~mduigou/7065380/0/webrev/
>> > For the unit test ignore the diffs and view the "New" file--webrev
>> doesn't understand "hg copy".
>> > Thanks,
>> > Mike
> 617-548-7007 (mobile)
More information about the core-libs-dev