Hi Mike,
The main body of the javadoc of method does state
176 * <p>The specified list must be modifiable, but need not be
resizable.
so I agree that a small javadoc update is needed to support this
reasonable expansion of behavior.
A further expansion would be "The list must be modifiable if not already
sorted," but I haven't checked to see if that would require further
implementation changes.
-Joe
On 03/01/2012 02:02 PM, Mike Duigou 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
