Hi,
Torsten Curdt wrote:
>>> Well, I am no expert but I think this cannot be done without huge
>>> hacks. Why
>>> you want to do this? Do you want to use it as a code generation tool?
>>
>> Yes... sort of.
>> I'm having some performance issues related to the use of reflection, I
>> was thinking to "extract" the Java code from the JXPath expression and
>> then use Janino to compile it, this way I would use reflection only
>> once (to generate the code).
>
> IMHO that's an ugly approach ...rather I would try to improve jxpath.
You are certainly entitled to your opinion :-)
I will take the example used in the JXPath user guide to illustrate what I want.
public class Employee {
public Address getHomeAddress(){
...
}
}
public class Address {
public String getStreetNumber(){
...
}
}
Employee emp = new Employee();
...
String jxpath_exp = "homeAddress/streetNumber"
String javaCode = JXPathContext.getJavaCode(Employee.class, jxpath_exp);
ExpressionEvaluator ee = new ExpressionEvaluator(javaCode, ...); // Janino
String sNumber = (String) ee.evaluate(new Object[] {emp} );
Maybe because my sense of aesthetics is skewed I fail to see the ugliness you speak of, but
I'm more than willing to be educated.
> When caching reflection you can get the same speed as native (at least
> in some areas).
Could you please elaborate on this... I don't understand what exactly should be cached.
The result of the evaluation? Maybe I'm missing something but if the Context object is always
changing is there a point in
"caching reflection"?
Another option would be to generate byte code internally
> (like XSLTC does)
Ok... that sure is a possibility, any pointers on how/where to start?
Although I'm a heavy user of JXPath I'm ashamed to admit that I barely know it's inner workings
Going through the source code stage just to avoid
> reflection speed sounds like the wrong approach to me.
It's just a possibility, what I really want is not to use reflection.
Thanks!
Luis Neves
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
|