commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael A. Smith" <>
Subject Re: [collection] Collections for primitives
Date Sat, 22 Jun 2002 22:24:22 GMT
On Sat, 22 Jun 2002, Ola Berg wrote:
> //might or might not throw ClassCastException
> if (myIntList.contains( \"Foo\")){...
> if (myIntList.indexOf( \"Foo\") != -1){...
> if (myIntList.lastIndexOf( \"Foo\")) != -1){...
> myIntList.remove( \"Foo\");
> Since the ClassCastException in the latter four methods are marked as
> \"(optional)\" in the javadocs, we should consider changing the
> implementation or clarifying the javadocs, else the user of the
> classes would have to rely on trial-and-error.

In my opinion, if you're asking an int based collection for the presence 
of a String, it's an error in your program and warrants the throwing of 
an exception (ClassCastException) at runtime.  If you think an addition 
to the documentation is warranted even though the contract states it 
might be thrown when an ineligible element is passed, then please post a 
patch to that effect.

> I think that the lookup methods shouldn\'t throw a
> ClassCastException, because that would make it easier for people to
> query a group of collections for the occurence of certain objects in a
> general fashion, without having to deal with the type-safe lists in a
> special (and tedious) way:
> if (object instanceof CertainType){
>     certainTypeList.contains( object);
> }
> if (object instanceof CertainType2){
>     certainType2List.contains( object);
> }
> etc...
> Note that this would be a usable behaviour for any type-safe list.

I can't think of any reason who you'd be mising type-safe collections of
one kind with non-type-safe collections or type-safe collections of a 
different king.  In all cases I can think of, it seems to be a 
problem in the design, not with the implementation.  Can you provide a 
use-case where such an implementation would be used?

> Next problem is the methods that deals with collections. What I can
> see, the addAll() methods should behave like the add() methods, ie.
> throw a ClassCastException.

What's the problem?  

> I suggest that the containsAll(), removeAll() and retainAll() methods
> don\'t throw a ClassCastException. containsAll() could simply return
> false, and non-throwing removeAll() and retainAll() are useful when
> you have Collections with mixed types as arguments (that would be
> useful in addAll() too, but since such behaviour would break the
> Collection contract...)

Essentially the same issues as above.  And I think your comment about 
addAll is exactly why this is the case.  To use the behavior you 
describe, you'd have to have the same functionality on add, but that 
breaks the contract.  Without that, the API is inconsistent.  

> And since the removeAll() IMO shouldn\'t throw a ClassCastException,
> remove() shouldn\'t either, for consistency.

same issues. 


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message