[jdom-interest] Prepping JDOM 2.4 - question about XPath API

[Rolf Lear]

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 <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:
>>
>> https://github.com/hunterhacker/jdom/issues/99
>>
>> Rolf
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://www.jdom.org/mailman/options/jdom-interest/youraddr@yourhost.com
>