You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Luis Neves <ln...@netcabo.pt> on 2006/03/07 15:59:25 UTC
[jxpath] Java code from JXpath expression
Hi all,
Is there some way of extracting the java code that is equivalent to the JXpath Expression?
Let's take the example from the JXpath main page.
1)
Address address = (Address) JXPathContext.newContext(vendor).
getValue("locations[address/zipCode='90210']/address");
2)
Address address = null;
Collection locations = vendor.getLocations();
Iterator it = locations.iterator();
while (it.hasNext()){
Location location = (Location)it.next();
String zipCode = location.getAddress().getZipCode();
if (zipCode.equals("90210")){
address = location.getAddress();
break;
}
}
I want to extract 2) as String from the JXpath expression in 1).
Did I made sense? Can this be done?
Regards,
Luis Neves
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
RE: [jxpath] Java code from JXpath expression
Posted by Tahir Akhtar <ta...@spectrum-tech.com>.
I guess, you are right. These were just my two cents. Best of luck in your
search !
Regards,
Tahir
-----Original Message-----
It's not that easy :-)
The org.apache.commons.jxpath.CompiledExpression is a compiled JXpath
expression it's not compiled Java code.
It's faster than parsing and compiling the expression every time but it
still uses reflection on evaluation.
Regards,
Luis Neves
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 268.2.0/275 - Release Date: 3/6/2006
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [jxpath] Java code from JXpath expression
Posted by Luis Neves <ln...@netcabo.pt>.
Tahir Akhtar wrote:
> Hi Luis,
>
> I think what you need is a compiled JXPath expression (instance of
> org.apache.commons.jxpath.CompiledExpression).
>
> * To acquire a CompiledExpression, call JXPathContext.compile()
It's not that easy :-)
The org.apache.commons.jxpath.CompiledExpression is a compiled JXpath expression it's not compiled Java code.
It's faster than parsing and compiling the expression every time but it still uses reflection on evaluation.
Regards,
Luis Neves
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [jxpath] Java code from JXpath expression
Posted by Dmitri Plotnikov <dm...@apache.org>.
Let me add a few observations based on my my admittedly fading knowledge of JXPath.
1. I believe that byte code generation would improve JXPath performance in most cases. JXPath has the overhead of handling heterogenous object models. It needs to allocate and maitain NodePointers and such, which is very expensive. And, of course it uses reflection (and yes, it caches as much of it as it can). XML-based systems like XSLT don't have such overhead, so they are likely to perform better. I am sure much of JXPath's overhead could be avoided through code generation. Not all though: you would still need to fall back on generic code in unpredictable cases like untyped Maps, Lists, properties of type "Object", containers, custom object models etc.
<aside>
I was astonished to see that converting a static HashMap to a highly optimized generated tree of switch-statements does not meet expectations. I built such a generator and discovered that even after factoring out the code generation itself, performance of the generated code was several times worse than that of the HashMap class.
How about a challenge: given an arbitrary list of string-key/value pairs, build byte-code that will consistently beat the corresponding HashMap object. It somebody succeeds at this, it could be generally useful for the community. I'll be happy to post my code generator so you could poke holes in it.
</aside>
2. It is certainly _possible_ to build a compiler from XPath to byte code. It will be more complex than the one in XSLT, because it will have to do what XSLT does plus handle non-XML based object models. All I am saying, is that it would be very difficult to build such a code generator and would require a team of developers. So far I've been handling JXPath by myself, but this task is way beyond the time I could personally contribute to JXPath.
3. Even with a compiler you can always write a poorly performing XPath. The issue is the same as with databases: if your query requires scans through large collections of objects, you'll get poor performance, compiler or no compiler. So, always make sure that the XPath itself is optimized. Use the map() and id() functions as much as you can. You can also use custom extension functions that would take care of the expensive steps.
All that said, JXPath-bytecode compiler sounds feasible though difficult and would certainly make an exciting project. Looking for volunteers!
Cheers,
- Dmitri
----- Original Message ----
From: Torsten Curdt <tc...@apache.org>
To: Jakarta Commons Users List <co...@jakarta.apache.org>
Sent: Tuesday, March 7, 2006 11:07:46 PM
Subject: Re: [jxpath] Java code from JXpath expression
On 08.03.2006, at 14:31, Dmitri Plotnikov wrote:
> 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.
Well if you can generate source code that compiled really improves
performance then surely you can also directly generate the byte code
instead ...no idea how the generated code needs to look like though.
TBH I don't have much of a clue how jxpath does its magic ;)
>>> IMHO that's an ugly approach ...rather I would try to improve
>>> jxpath.
>>
>> You are certainly entitled to your opinion :-)
Thanks ;)
>> 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.
It's just unnecessary overhead. Besides I am not a big fan of source
code generation in general (mostly because it's a one-way street) You
should ask yourself "who will ever look at the code"? ...if no one
does it does not make much sense to pipe it through an compiler IMO.
>>> 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"?
Obtaining the Method and Field objects is expensive.
Once you have them - keep them! ...and you will save quite some cpu
cycles. If jxpath already does that I am not sure the source code
generation detour will give you the speed improvement you are looking
for.
>> 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?
First you need to find out what the code needs to look like! Compare
and see whether it really makes a huge difference - or is possible at
all.
Then have a look at BCEL, ASM and of course XSLTC
>> Although I'm a heavy user of JXPath I'm ashamed to admit that I
>> barely know it's inner workings
Same here ... Dmitri just did a too good of a job :)
>> 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.
...if that is really possible at all.
cheers
--
Torsten
Re: [jxpath] Java code from JXpath expression
Posted by Torsten Curdt <tc...@apache.org>.
On 08.03.2006, at 14:31, Dmitri Plotnikov wrote:
> 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.
Well if you can generate source code that compiled really improves
performance then surely you can also directly generate the byte code
instead ...no idea how the generated code needs to look like though.
TBH I don't have much of a clue how jxpath does its magic ;)
>>> IMHO that's an ugly approach ...rather I would try to improve
>>> jxpath.
>>
>> You are certainly entitled to your opinion :-)
Thanks ;)
>> 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.
It's just unnecessary overhead. Besides I am not a big fan of source
code generation in general (mostly because it's a one-way street) You
should ask yourself "who will ever look at the code"? ...if no one
does it does not make much sense to pipe it through an compiler IMO.
>>> 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"?
Obtaining the Method and Field objects is expensive.
Once you have them - keep them! ...and you will save quite some cpu
cycles. If jxpath already does that I am not sure the source code
generation detour will give you the speed improvement you are looking
for.
>> 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?
First you need to find out what the code needs to look like! Compare
and see whether it really makes a huge difference - or is possible at
all.
Then have a look at BCEL, ASM and of course XSLTC
>> Although I'm a heavy user of JXPath I'm ashamed to admit that I
>> barely know it's inner workings
Same here ... Dmitri just did a too good of a job :)
>> 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.
...if that is really possible at all.
cheers
--
Torsten
Re: [jxpath] Java code from JXpath expression
Posted by Dmitri Plotnikov <dm...@apache.org>.
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" <ln...@netcabo.pt>
To: <co...@jakarta.apache.org>
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: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [jxpath] Java code from JXpath expression
Posted by Luis Neves <ln...@netcabo.pt>.
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
Re: [jxpath] Java code from JXpath expression
Posted by Torsten Curdt <tc...@apache.org>.
>> 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.
When caching reflection you can get the same speed as native (at least
in some areas). Another option would be to generate byte code internally
(like XSLTC does) Going through the source code stage just to avoid
reflection speed sounds like the wrong approach to me.
...but even more important - if you want to optimize try to optimize
the larger picture first. Usually you earn much more when improving
the algorithm instead of the plain code.
My 2 cents
--
Torsten
RE: [jxpath] Java code from JXpath expression
Posted by Tahir Akhtar <ta...@spectrum-tech.com>.
Hi Luis,
I think what you need is a compiled JXPath expression (instance of
org.apache.commons.jxpath.CompiledExpression).
* To acquire a CompiledExpression, call JXPathContext.compile()
I have never used it anyway :). If it works please let me know, I might need
something similar very soon.
Regards
Tahir
-----Original Message-----
From: news [mailto:news@sea.gmane.org] On Behalf Of Luis Neves
Sent: Tuesday, March 07, 2006 8:27 PM
To: commons-user@jakarta.apache.org
Subject: Re: [jxpath] Java code from JXpath expression
Hi,
Tahir Akhtar 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).
Regards,
Luis Neves
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 268.2.0/275 - Release Date: 3/6/2006
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 268.2.0/275 - Release Date: 3/6/2006
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [jxpath] Java code from JXpath expression
Posted by Luis Neves <ln...@netcabo.pt>.
Hi,
Tahir Akhtar 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).
Regards,
Luis Neves
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
RE: [jxpath] Java code from JXpath expression
Posted by Tahir Akhtar <ta...@spectrum-tech.com>.
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?
-----Original Message-----
From: news [mailto:news@sea.gmane.org] On Behalf Of Luis Neves
Sent: Tuesday, March 07, 2006 7:59 PM
To: commons-user@jakarta.apache.org
Subject: [jxpath] Java code from JXpath expression
Hi all,
Is there some way of extracting the java code that is equivalent to the
JXpath Expression?
Let's take the example from the JXpath main page.
1)
Address address = (Address) JXPathContext.newContext(vendor).
getValue("locations[address/zipCode='90210']/address");
2)
Address address = null;
Collection locations = vendor.getLocations();
Iterator it = locations.iterator();
while (it.hasNext()){
Location location = (Location)it.next();
String zipCode = location.getAddress().getZipCode();
if (zipCode.equals("90210")){
address = location.getAddress();
break;
}
}
I want to extract 2) as String from the JXpath expression in 1).
Did I made sense? Can this be done?
Regards,
Luis Neves
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 268.2.0/275 - Release Date: 3/6/2006
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 268.2.0/275 - Release Date: 3/6/2006
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org