You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Ola Berg <ol...@arkitema.se> on 2002/06/22 22:36:52 UTC

[collection] Collections for primitives

The collections for primitves has dangerous behaviour in the methods where you recieve an Object as an argument, where it just tries to cast the argument to an Integer (or Float etc). This will result in a ClassCastException, which could be appropriate somtimes, but not in all cases.

Shouldn\'t myIntList.contains( \"Foo\") result in false?

Shouldn\'t myIntList.[lastI | i]ndexOf( \"Foo\") result in -1?

Shouldn\'t myIntList.add( \"Foo\") result in false, indicating that the object couldn\'t be added? 

And so on (remove() etc)?

Should I fix this and send a patch to someone, or is it the desired behaviour? If it is desired, I could make javadoc comments about it instead.

/O

--------------------
ola.berg@arkitema.se
0733 - 99 99 17

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [collection] Collections for primitives

Posted by "Michael A. Smith" <ma...@apache.org>.
On Sat, 22 Jun 2002, Ola Berg wrote:

> The collections for primitves has dangerous behaviour in the methods
> where you recieve an Object as an argument, where it just tries to
> cast the argument to an Integer (or Float etc). This will result in a
> ClassCastException, which could be appropriate somtimes, but not in
> all cases.
> 
> Shouldn\'t myIntList.contains( \"Foo\") result in false?

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.
http://java.sun.com/j2se/1.4/docs/api/java/util/Collection.html#contains(java.lang.Object)

This is not alted in the List contract.
http://java.sun.com/j2se/1.4/docs/api/java/util/List.html#contains(java.lang.Object)

> Shouldn\'t myIntList.[lastI | i]ndexOf( \"Foo\") result in -1?

No.  Same reasons as above.
http://java.sun.com/j2se/1.4/docs/api/java/util/List.html#indexOf(java.lang.Object)
http://java.sun.com/j2se/1.4/docs/api/java/util/List.html#lastIndexOf(java.lang.Object)
 
> Shouldn\'t myIntList.add( \"Foo\") result in false, indicating that
> the object couldn\'t be added?

No. Same reason as above.
http://java.sun.com/j2se/1.4/docs/api/java/util/List.html#add(java.lang.Object)

> And so on (remove() etc)?

No. Same reason as above.

> Should I fix this and send a patch to someone, or is it the desired
> behaviour? If it is desired, I could make javadoc comments about it
> instead.

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.

regards,
michael


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>