<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 01/18/2012 01:12 AM, Michael Kay wrote:
<blockquote cite="mid:4F168CF7.2000706@saxonica.com" type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<meta name="Generator" content="MS Exchange Server version
6.5.7036.0">
<title>Re: [jdom-interest] JDOM2 and Runtime Exceptions</title>
<!-- Converted from text/plain format --><font size="2">I don't
think you'll please everyone here, but even without the </font>
<font size="2">compatibility implications, I'm not convinced that
moving to unchecked </font>
<font size="2">exceptions would be an improvement.</font>
<p>
</p>
</blockquote>
<br>
We use JDOM in our hand-written because it is a convenient,
expressive API, giving much of the compactness and other benefits we
see from XPath itself and other higher-level XML interfaces such as
XQuery.<br>
<br>
However, we haven't found the JDOM1 XPath Java interface to be
convenient or expressive, because of the verbosity and the checked
exceptions, which in our case are all programming errors of one sort
or another. (We don't let end users type in XPath expressions.)
Instead, we use a static JDOMUtil wrapper class with methods such as
selectElement, selectElements, selectAttributes, selectContent, and
ref (leaf-node value).<br>
<br>
So for us, the JDOM XPath API is a implementation of a way to run
XPath expressions over JDOM objects, and not a convenient,
expressive API that we use to hand write Java code.<br>
<br>
JDOM2 with the filters may offer an expressive API that would let us
do away with the profusion of select* utility methods, but with
checked exceptions it still won't be convenient, and we still won't
use it directly.<br>
<br>
Leaving in the checked exceptions means less migration headache for
other users, and since we're not going to use it directly, it
doesn't matter much. Another reason we may shift away from JDOM
XPath API is that we're disenchanted with Jaxen as well and are
hoping to find a fast (at runtime) way to use Saxon on JDOM from
hand-written Java code. That probably won't use the JDOM XPath API
at all.<br>
<br>
Leigh.<br>
<br>
<br>
<br>
</body>
</html>