[ Osvaldo Pinali Doederlein ] [ Osvaldo Pinali Doederlein ] [concurrency-interest] need to use collection.sort w. CopyOnWriteArrayList but cant.....

Gregg G. Wonderly gregg.wonderly@pobox.com
Thu, 03 Jun 2004 21:37:59 -0500

>> I would suggest that perhaps the easist thing for people who need the
>> inheritance hierachy, or some other class relationship is to create wrapper
>> classes that make the language of programming fit the discriptive language 
>> the problem domain.  Then, you can change what you call, or work out 
>> details for your special case, and everyone can benefit from having a 
>> base API that doesn't try to support a particular problem domain to the
>> exclusion of others.
>Unfortunately this won't work, and even if it did, it's a workaround
>for a bug.  The current implementation of Collections.sort() breaks
>the semantics of the collections API: sort(List) should work with any
>implementation of List (I'm not requiring a performant behavior, only
>correct behavior). The problem is that the contracts involved in this
>problem are multiple and have subtle dependencies:
>* List must provide a ListIterator; that's OK.
>* ListIterator is free to implement set() or not; that's OK too.
>* Collections.sort(List) promises to sort any List, with the single
>   (and obvious) condition that "specified list must be modifiable".
>   But that's not specific enough, it doesn't state "modifiable through
>   iterators", and such constraint wouldn't make any sense.

This is an oversight in documentation for sure.  I understand you feelings 
about this.  But, specifically, the ListIterator is the optimal implementation 
of access to the list members, and so I can see why sort(List) uses that for 
write access, as the reply related to linked lists pointed out already.

I thinking that a more type centric fix at this point would be to create 
something like the following interfaces. The existing Collections.sort(List) 
could be deprecated, and a new Collections.sort(WriteableList) could be added 
that would make the contract visible with type information.

public interface WriteableList extends List {
	public WriteableListIterator writeableListIterator();

public interface WriteableListIterator extends ListIterator {
	public void set( Object obj ) throws

And more specifically, I was trying to say that you could create a sort 
implementation that manifested these contracts into your application so that 
you would be sure to have the writeable lists visible.  Probably many others 
have already encountered this and worked around it in some way.  It would be 
nice if more people would file bug reports for things that you can work around.
gregg@cytetech.com  (Cyte Technologies Inc)