What about exception cases where the single element is not comparable? http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5045147 Consider the following: ========= Object[] a = new Object[]{new Object()}; Arrays.sort(a); List l = Arrays.asList(a); //Evil raw type Collections.sort(l); ======== On JDK1.6u31, Arrays.sort passes but, Collections.sort fails with a class cast. Per the method contracts, both Arrays.sort and Collections.sort should fail in non-comparable single element case. So for this patch, the length check be performed to prevent the element swap that causes the unsupported operation exception but not prevent the call to Arrays.sort. That way both methods always have the same type checking behavior. Jason
> From: mike.dui...@oracle.com > Subject: RFR 7065380 : Allow Collections.sort to sort > Collections.singletonList() result > Date: Thu, 1 Mar 2012 11:50:49 -0800 > To: core-libs-dev@openjdk.java.net > > 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
