[jdom-interest] JDOM2 and Runtime Exceptions - and XPath
jdom at tuis.net
Sun Feb 26 11:06:18 PST 2012
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.
> I would second that especially since Jaxen does not support XPath2
> currently and it doesn't look like it would in the near future.
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:
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)
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
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
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.
More information about the jdom-interest