dev@javaserverfaces.java.net

Re: Revist jsf-tools/template-src/TypedCollections.java

From: Ryan Lubke <Ryan.Lubke_at_Sun.COM>
Date: Mon, 16 Oct 2006 09:18:13 -0700

Tony & Pat Robertson wrote:
> 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.
Sounds good to me. Do you have time to take care of it?
>
> What do you think?
>
> On 10/12/06, *Ryan Lubke* <Ryan.Lubke_at_sun.com
> <mailto: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
> <mailto:dev-unsubscribe_at_javaserverfaces.dev.java.net>
> For additional commands, e-mail:
> dev-help_at_javaserverfaces.dev.java.net
> <mailto:dev-help_at_javaserverfaces.dev.java.net>
>
>