[jdom-interest] Prepping JDOM 2.4 - question about XPath API
jdom at tuis.net
Mon Oct 29 05:40:26 PDT 2012
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.
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.
> On Oct 28, 2012, at 17:52, Rolf Lear <jdom at tuis.net> 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:
>> To control your jdom-interest membership:
More information about the jdom-interest