geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Nokleberg <>
Subject Re: [XML Parsing]
Date Fri, 05 Sep 2003 16:36:51 GMT
Dain Sundstrom wrote:

> On Friday, September 5, 2003, at 01:57 AM, Chris Nokleberg wrote:
>> 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.

I took a look at the DynamicMBean API. It would have been a lot better for
performance if the name and types were combined into a single String
signature...oh well. I suppose that even if you have a unique match by name
that you still need to check to make sure the signature types match? Given
that, you're probably better off using hashing along with a special
comparator or something similar. You might want to look at the CGLIB
KeyFactory class, it will save you from writing all the tedious hashCode
and equals code, at the cost of one new object instance per lookup.

> 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);

That's not hard. Even better for performance would be:
  FastClass fastClass = FastClass.create(javaClass);
  int index = fastClass.getIndex(javaMethod);
  // time passes
  fastClass.invoke(index, instance, args);

Since you have to store other metadata per method I assume you could stash
the index away 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)
> 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.

Actually we use setAccessible to directly invoke the protected defineClass
method on whatever ClassLoader is passed in. As long as the SecurityManager
doesn't get in the way I think it should work the way you want? If you want
to take a look, the code in question is in n.s.c.util.BasicCodeGenerator.


View raw message