+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.dui...@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. > > Mike > > 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.dui...@oracle.com> > wrote: > > 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 > > > > -- Vitaly 617-548-7007 (mobile)
