On 2/03/2012 10:22 AM, Joe Darcy wrote:
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.
Sorry I didn't check the spec beforehand. I agree a spec change is
needed to match this change in behaviour. I don't see an issue with
changing the spec to say that sort() is a no-op if the collection is
empty or only has one element.
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.
I think you might need more code to implement this. You have to be able
to test if the list is sorted if you find it is not modifiable.
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.
This is a specification stating under what conditions exceptions _will_
be thrown. The JCK folks write tests to check these kinds of
preconditions and expect to get exceptions if the stated precondition is
not met. If you want exceptions to be "optional" then that has to be
part of their spec.
David
-----
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
