On 13/03/2012 5:08 AM, Jason Mehrens wrote:
I'm not really confident about proposing "assertions as lint detection" rather than
adding explicit checks. We wouldn't (and don't) use optional assertions for array bounds
checking. This has clearly been the right choice. I'm still considering my>>feelings
about whether to be hardline and suggest we add the checks to Arrays.sort
Thoughts anyone?
Add wiggle room to the throws CCE javadocs to suggest detection doesn't occur
for all cases.
Reading over the bug report again, the justification example is flawed. The
caller only knows it is safe to call sort when the documentation for 'generate'
states that the returned list is mutable. If the returned list is mutable, it
is not a Collections$SingletonList. If 'generate' returns an unmodifiable list
the call has to make a mutable copy. If the caller has to create a copy, the
caller could perform the size check first.
Close as Not a bug??
Well it's not a bug it is a RFE. :) But I agree that the example is a
little flawed in that generate() would not reasonably be able to
generate mutable lists in some cases and immutable lists in others.
I find the restriction on empty/singleton lists unnecessary, but not
sure it is worth jumping through the spec hoops to change this.
David
Jason
