From jdom at tuis.net Sun Oct 28 14:37:24 2012 From: jdom at tuis.net (Rolf Lear) Date: Sun, 28 Oct 2012 17:37:24 -0400 Subject: [jdom-interest] Prepping JDOM 2.4 - question about XPath API Message-ID: <508DA594.6080405@tuis.net> Hi all. I have been working on a Saxon interface layer for the past few weeks... and I realized that there is the option of adding support for a library-specific 'index' for calculating XPaths. For example, Saxon builds an 'index' in to the document which it then uses to 'accelerate' the XPath queries. If an index is built once, and then reused multiple times, it can improve the performance of the XPath evaluation quite significantly (in my testing, it can 'halve' the evaluation time. I have played with various scenarios, but I think the best way to support 'indexes' is to incorporate them at the 'Factory' level. Thus, add the following: new method: StaticIndex XPathFactory.buildIndex(Object) this method will build a 'StaticInstance' instance which contains the information needed by the factory to have a static 'index' in to the document or node. org.jdom2.xpath.StaticIndex - a class containing whatever the factory wants.... add versions of the methods evaluate(...), evaluateFirst(...), and diagnose(...) which take a StaticIndex argument in addition to the context. I know this is a fair bit of detail for people not necessarily familiar with the code, but the consequence of this change would be that if someone has already extended the XPath API with their own implementation (which I don't think anyone has done), they will need to make code changes because the underlying API will change a bit. It will also mean that people who wrote code against JDOM 2.4 will not be able to run with JDOM 2.3 or older. I don't believe any of this will be a problem, but I thought I would get some input before I commit.... I have submitted Issue 99 to track: https://github.com/hunterhacker/jdom/issues/99 Rolf From garydgregory at gmail.com Sun Oct 28 16:14:45 2012 From: garydgregory at gmail.com (Gary Gregory) Date: Sun, 28 Oct 2012 19:14:45 -0400 Subject: [jdom-interest] Prepping JDOM 2.4 - question about XPath API In-Reply-To: <508DA594.6080405@tuis.net> References: <508DA594.6080405@tuis.net> Message-ID: <-4016070385345780187@unknownmsgid> You may want to call it JDOM 3 then. In the Apache projects I work on, a major version change signals the allowance of API changes that are not binary compatible. Gary On Oct 28, 2012, at 17:52, Rolf Lear wrote: > Hi all. > > I have been working on a Saxon interface layer for the past few weeks... and I realized that there is the option of adding support for a library-specific 'index' for calculating XPaths. > > For example, Saxon builds an 'index' in to the document which it then uses to 'accelerate' the XPath queries. If an index is built once, and then reused multiple times, it can improve the performance of the XPath evaluation quite significantly (in my testing, it can 'halve' the evaluation time. > > I have played with various scenarios, but I think the best way to support 'indexes' is to incorporate them at the 'Factory' level. Thus, add the following: > > new method: StaticIndex XPathFactory.buildIndex(Object) > this method will build a 'StaticInstance' instance which contains the information needed by the factory to have a static 'index' in to the > document or node. > > org.jdom2.xpath.StaticIndex - a class containing whatever the factory wants.... > > add versions of the methods evaluate(...), evaluateFirst(...), and diagnose(...) which take a StaticIndex argument in addition to the context. > > > > I know this is a fair bit of detail for people not necessarily familiar with the code, but the consequence of this change would be that if someone has already extended the XPath API with their own implementation (which I don't think anyone has done), they will need to make code changes because the underlying API will change a bit. > > It will also mean that people who wrote code against JDOM 2.4 will not be able to run with JDOM 2.3 or older. > > I don't believe any of this will be a problem, but I thought I would get some input before I commit.... > > I have submitted Issue 99 to track: > > https://github.com/hunterhacker/jdom/issues/99 > > Rolf > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com From jdom at tuis.net Mon Oct 29 05:40:26 2012 From: jdom at tuis.net (Rolf Lear) Date: Mon, 29 Oct 2012 08:40:26 -0400 Subject: [jdom-interest] Prepping JDOM 2.4 - question about XPath API In-Reply-To: <-4016070385345780187@unknownmsgid> References: <508DA594.6080405@tuis.net> <-4016070385345780187@unknownmsgid> Message-ID: <508E793A.3050402@tuis.net> Gary, All. I think you are right, but I don't think 3.0.0 is the way I want to go... 2.1.0 is better. In this case the API change is fully compatible going forward... code written for any 2.x version will work with 2.1.x, but *some code* written for 2.1.x will not work with 2.0.x. Specifically, I am intending to *extend* the API, and not change any existing methods signatures. Also, I am in the process of working on the Saxon support in JDOM for XSLT and XPath: few reasons... - faster than Jaxen - supports XPath 2.0 - good to have diversity THis work is what has inspired this change to add a static index concept to the XPath API. In reality, there is no rush to implement the API changes until the Saxon interfaces is ready too. This will likely be at least a month or three away..... So, I think I am answering my own questions here: Plan a 2.1.x release of JDOM for the new-year 2013 timeframe. Put these API changes and Saxon support in at the same time.... Release 2.0.4 in the next few days with other pending fixes. Thanks Rolf On 28/10/2012 7:14 PM, Gary Gregory wrote: > You may want to call it JDOM 3 then. In the Apache projects I work on, > a major version change signals the allowance of API changes that are > not binary compatible. > > Gary > > On Oct 28, 2012, at 17:52, Rolf Lear wrote: > >> Hi all. >> >> I have been working on a Saxon interface layer for the past few weeks... and I realized that there is the option of adding support for a library-specific 'index' for calculating XPaths. >> >> For example, Saxon builds an 'index' in to the document which it then uses to 'accelerate' the XPath queries. If an index is built once, and then reused multiple times, it can improve the performance of the XPath evaluation quite significantly (in my testing, it can 'halve' the evaluation time. >> >> I have played with various scenarios, but I think the best way to support 'indexes' is to incorporate them at the 'Factory' level. Thus, add the following: >> >> new method: StaticIndex XPathFactory.buildIndex(Object) >> this method will build a 'StaticInstance' instance which contains the information needed by the factory to have a static 'index' in to the >> document or node. >> >> org.jdom2.xpath.StaticIndex - a class containing whatever the factory wants.... >> >> add versions of the methods evaluate(...), evaluateFirst(...), and diagnose(...) which take a StaticIndex argument in addition to the context. >> >> >> >> I know this is a fair bit of detail for people not necessarily familiar with the code, but the consequence of this change would be that if someone has already extended the XPath API with their own implementation (which I don't think anyone has done), they will need to make code changes because the underlying API will change a bit. >> >> It will also mean that people who wrote code against JDOM 2.4 will not be able to run with JDOM 2.3 or older. >> >> I don't believe any of this will be a problem, but I thought I would get some input before I commit.... >> >> I have submitted Issue 99 to track: >> >> https://github.com/hunterhacker/jdom/issues/99 >> >> Rolf >> _______________________________________________ >> To control your jdom-interest membership: >> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com >