[jdom-interest] JDOM2 and Runtime Exceptions - and XPath

[Rolf Lear]

On 25/02/2012 7:51 PM, Victor Toni wrote:
> 2012/1/19 Leigh L Klotz Jr <leigh.klotz at xerox.com
> <mailto:leigh.klotz at xerox.com>>
>
>     Given what I decided about our usage of org.jdom.xpath packages
>     being isolated, the issue of exception checking isn't a big one for
>     me, but sadly that's because we can't much use it anyway.
>
>     If you're interested in doing refactoring, making it easier to use a
>     different XPath implementation would be my suggested goal.
>
>
>     Leigh.
>
>
> I would second that especially since Jaxen does not support XPath2
> currently and it doesn't look like it would in the near future.
>
> Victor


Hi all.

Great to see some discussion on this.

The XPath API has been completely reworked, and it is an area where I 
think some close 'objective' verification would be useful.

In regard to the exceptions, I have currently implemented it using 
IllegalArgumentException, IllegalStateException, and 
NullPointerException. This is the same sort of handling that similar 
API's use (namely javax.xml.xpath.* and java.util.regex.*)

On the actual XPath side of things....

The new API is described here: 
https://github.com/hunterhacker/jdom/wiki/JDOM2-Feature:-XPath-Upgrade

In essence, the new API is now more similar to javax.xml.xpath.* than it 
is to the JDOM 1 XPath class.

I have tried to validate the API myself, and I have done it y 
implementing a direct Xalan backend, as well as a more general 
JAXB-backend. You can see the implementations (xalan) 
https://github.com/hunterhacker/jdom/tree/master/contrib/src/java/org/jdom2/contrib/xpath/xalan 
and (java) 
https://github.com/hunterhacker/jdom/tree/master/contrib/src/java/org/jdom2/contrib/xpath/java

With the 'java' implementation I have a broken situation where the 
implementation cannot determine the return-type of the XPath, and the 
only available returns types are String, Boolean, Double, and 
NodeList... and you have to know the required return typebefore running 
the expression.

This will be very broken in XPath2.0

Most actual XPath implementations (Xalan, Jaxen, Saxon - all the ones I 
have inspected) have a way to handle unknown-at-run-time return types. 
The new JDOM2 XPath API handles that situation well.... and it is what 
is most useful for XPath2.0

So, what I have done is I have plugged in two additional implementations 
for XPath in the the JDOM2 API already (as well as the base Jaxen 
inplementation).

The way I did that was to create a thin DOM wrapper for JDOM, and then 
to just convince the implementation that it is inspecting DOM (not JDOM).

It would be better to use the more native mechanisms for the 
implementation instead of creating a DOM wrapper. For example, in Jaxen 
we have a Navigator.

For Xalan, I started writing an Xalan 'DTM' for JDOM, but I got bogged 
down in some details, and I backed off because it was taking too much 
time. The DTM is not exactly intuitive... ;-) Also, I found it hard to 
tell Xalan what DTM version to use... while it appears to support any 
arbirary DTM, it has fixed ways to load the DTM, and I could not get 
around that.... I missed something, I think.

For Saxon it would be nice to build a JDOM 'ObjectModel' implementation. 
Again, I started playing with one, but only took it as far as 'I think 
this will work... but the details are time-consuming' (also, I know it 
works because the commercial versions of Saxon already do it....).

So, while the new JDOM2 API fails to fully 'wrap' the native Java XPath 
API, it will easily accommodate the actual implementations that are 
common (if the right glue is used) - Jaxen, Saxon, and Xalan.

If there's anyone who's got the time to investigate how to get the 
'native' model of JDOM built for any of the available XPath libraries 
then I will happily integrate it in to core.... right now I don't think 
the DOM-wrapper versions I did are suitable for core though.

Rolf