geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Nokleberg <ch...@sixlegs.com>
Subject Re: [XML Parsing]
Date Fri, 05 Sep 2003 06:57:13 GMT
Dain Sundstrom wrote:
> Cool. I didn't know you were on this list.  I really love cglib.  It is
> easy to use and super fast.

Glad to hear it. I just lurk on a lot of lists using GMANE.

> For this case we need to do reflective calls on the public methods of a
> target instance.  Right now I just create a MethodProxy for each method
> we want to call and I keep that proxy in a hash map (BTW do you know of
> a faster map style data structure available?) by name with a bunch of
> other information we need for the invocation.   If I could generate a
> single class that for the entire target, I think that would be better.
> I thinking of something I can use like this:
> 
>    ReflectiveProxy myReflectiveProxy =
> ReflectiveProxy.create(myTargetClass);
>    MethodProxy methodProxy =
> myReflectiveProxy.getMethodProxy(myTargetMethod);
>    methodProxy.invoke(instance, args);
> 
> I'm not sure this is possible to do this and be fast.  I'm concerned
> about generated code being able locate the correct method to call
> quickly (quicker than a hash map).

Since the set of keys is fixed, it actually is possible to generate code
faster than a generic hash map.

In CVS we have a BeanMap class that can use two different techniques for
quickly looking up a bean property by name. I've written a couple of blog
entries describing them:

  http://sixlegs.com/blog/java/cglib-stringswitch.html
  http://sixlegs.com/blog/java/cglib-stringswitch-hash.html

If your objects are actually beans you may be able to use BeanMap as is.
Otherwise it should be easy to adapt the code for your needs.

Even if you stick with a map of MethodProxys you might want to replace the
map with a "trie" for faster lookups. I think there was some talk about
this on commons-devel and/or tomcat-devel (it's good for URL matching too).

> On another issue, since we own the class loader implementation class,
> is there some interface we can add to have your dynamic classes loaded
> directly by our classloader instead of a sub classloader?

Across most of the API there is usually a provision for supplying the
classloader to generate the class with, is that what you mean? (I'm
guessing not)

Chris



Mime
View raw message