geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@coredevelopers.net>
Subject Re: [XML Parsing]
Date Fri, 05 Sep 2003 09:02:18 GMT
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
  *************************/


Mime
View raw message