On Friday, September 5, 2003, at 01:57 AM, Chris Nokleberg wrote:
Dain Sundstrom wrote:
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
Good stuff. I was thinking of the same thing when I was at JB, but the I found the byte code generation to be overwhelming.
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.
Unfortunately they we need generic method invocation.
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).
Definitely. My specific case is a bit complex. I am implementing the DynamicMBean interface which invoked methods by name (String) and parameter types (String[]). We could use a trie for this, but I still need to look up some other metadata to handle the invocation like the cache time limit and cached value. So I think we would end up with two tries.
A good start for us and I think a bunch or other projects would be to have a fast reflection interface to a class. I am thinking of something like this:
FastClass fastClass = FastClass.create(javaClass); fastClass.invoke(javaMethod, instance, args);
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)
I assume you are generating the byte code as a byte array, creating a sub class loader that will let you specify the bytes of a class directly, and finally loading the class. Can we implement an interface on our class loader that will let you pipe the bytes directly into our instance so you don't have to create the sub class loader.
-dain
/************************* * Dain Sundstrom * Partner * Core Developers Network *************************/
