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>