Hi Ryan,
When putting that class in place, I realized that it is not a 100% solution
anyway (if the collection type is not actually the type in the cast, but
happens to contain no members, or currently only members of that type, that
does not guarrantee that the original creator of the collection will not add
other types later). To be sure, you would need to check that the collection
type was a "CheckedCollection" or equivalent. Although you can do this, you
can't tell what the type of the checked collection is (this is the subject
of a JDK RFE that hopefully will go into a future JDK release -- see
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6471768).
Anyway, the current solution IS a compromise, and more of a place holder
until something better is available (so all the type cast problems are
removed from the other code and put in one place).
On reflection, I think putting the iteration through the collection into a
method call that only gets called from an assert statement might be a better
way to do it.That way, normally running code will not incur the overhead,
but if you are trying to track down problems you can turn on assertion
checking when running the JVM.
What do you think?
On 10/12/06, Ryan Lubke <Ryan.Lubke_at_sun.com> wrote:
>
> Hey All,
>
> I wasn't thinking about performance when reviewing the change bundle
> that included the addition of
> jsf-tools/template-src/TypedCollections.java.
>
> This was added primarily to get around various cast compiler warnings
> that became prevalent when we moved to 1.5.
>
> My concern is that TypedCollections does an iteration through the
> collection
> to ensure the types of said collection match the input arguments. If not
> then throw a ClassCastException. This can potentially result in two
> iterations
> over the same collection.
>
> Before this was in place, we would just let the ClassCastException happen
> during iteration, so I suggest we go back to doing that and remove the
> type
> validation logic from TypedCollections.
>
> Thoughts?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>
>