Hi,
I have thought about using this type of compilation to byte code.
Unfortunately, I got mired in the tremendous _potential_ complexity of data
models that JXPath works with. Imagine that you have an expression that
needs to traverse a path through a graph with the root in JavaBean, followed
by a property that is declared to be of type "Object". What type is it
really? We don't know 'till the runtime, at which point we discover that it
really is a Map that contains a List that contains an object handled by a
custom NodeFactory. That NodeFactory takes us to a Container that resolves
into a DOM object. And then we do a few steps through the DOM tree. That
last step kind-of resembles XPath :-)
I just could not figure out how to translate all of this complexity to Java
or byte code reliably.
- Dmitri
----- Original Message -----
From: "Luis Neves" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, March 07, 2006 5:39 PM
Subject: Re: [jxpath] Java code from JXpath expression
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
