commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ola Berg <>
Subject Re: [collection] Collections for primitives
Date Sat, 22 Jun 2002 21:50:35 GMT
Ola wrote:
>> Shouldn\\\'t myIntList.contains( \\\"Foo\\\") result in false?

michael wrote:
>No.  The Collection.contains(Object) contract declares that a
>ClassCastException is thrown \"if the type of the specified element is
>incompatible with this collection\".  \"Foo\" is incompatible with an
>int collection.

Hmm, looking at the contract for Collection, it seems like it leaves a
lot for the implementors to decide:

Javadoc for java.util.Collection says:
Some collection implementations have restrictions on the elements that they may contain.
For example, some implementations prohibit null elements,
and some have restrictions on the types of their elements.

Attempting to add an ineligible element throws an unchecked exception,
typically NullPointerException or ClassCastException.

Attempting to query the presence of an ineligible element may throw an exception,
or it may simply return false;
some implementations will exhibit the former behavior and some will exhibit the latter.

More generally, attempting an operation on an ineligible element whose completion would
not result in the insertion of an ineligible element into the collection may
throw an exception or it may succeed, at the option of the implementation.
Such exceptions are marked as \"optional\" in the specification for this interface.

According to this, the following should be true about the List contract:

//should definitely throw ClassCastException
myIntList.add( \"Foo\");
myIntList.add( 12, \"Foo\");
myIntList.set( 12, \"Foo\");

//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.

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);


Note that this would be a usable behaviour for any type-safe list.

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.

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...)

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

>The throwing of a ClassCastException may not seem \"appropriate\", but
>it is already documented in the Collection contract (and also the
>List contract and Map contract).  There is no reason to \"fix\" it
>because it follows the contract.  Added documentation restating the
>documentation in Collection and List is doable, but not necessary in
>my opinion.

Since the contract states that there are room for
different implementation we should consider it. Either way, the path
chosen should be documented.

This isn\'t really about collections for primitives, but about
type-safe collections as a whole. I suggest that the strict behaviour
(throwing ClassCastExceptions) should be implemented as asserting
wrappers around the collection. The collection itself should chose the
permissive approach when the contract leaves room for it.


0733 - 99 99 17

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

View raw message