commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: Digester/Beanutils performance
Date Thu, 08 Aug 2002 14:08:35 GMT
On Wed, 7 Aug 2002, Craig R. McClanahan wrote:

> > At least for tomcat ( and modeler ) we have many calls to MethodUtils,
> > and it seems Class.getMethods() is the one on the top ( in OptimizeIt).
> >
> > I added a quick hash ( Class -> Method[] ) and OptimizeIt seems happy
> > ( and a slight reduction in the processing time ).
> >
> Just as a curiousity, you're testing on JDK 1.4, right?

1.4.1 (beta I think). I tried with IBM JDK1.3 also.

> There are cases where exact match is sufficient, and cases where you want
> the more loose matching (finding compatible arguments instead of identical
> ones).  IMHO, that's a tradeoff that the user should really be able to
> make, by letting it be configurable.

I agree. For example in JMX we know that no overloading is possible. And
in most digester code we also control the objects - and we can avoid 
problems. But for arbitrary code - the check is needed.

> > There is another problem in PropertyUtils ( again, only from optimize-it
> > ) - it seems it's using the Bean introspector, wich seems to do a lot
> > of stuff ( compared with what I know from IntrospectionUtils with the
> > simple get/set method ).
> >
> I'm +1 for impriving this, as long as it doesn't break backwards
> compatibility for people that depend on JDK introspector functionality
> (such as BeanInfo class support), at least in the default opearting mode.
> That's part of the price that JDK introspection costs, but it's well worth
> it when you need it.

That's why it may be a good idea to not change it, but add a separate 
'light' introspector - and have a way to specify which one will be used
by digester.

> > It would be worth looking a bit more into what ant and axis are doing -
> > they are also heavy introspection users.
> >
> > Probably putting all introspection stuff in beanutils is a good idea
> > ( or better than having 4 different commons components ), but things
> > are done quite differently, at least in tomcat33 Introspector.
> The other proposed home was commons-lang.

It's fine too - as long as all forms of introspection are there and share
some common patterns.


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

View raw message