Re: JDOM2 and Runtime Exceptions

On 01/18/2012 01:12 AM, Michael Kay wrote:
> I don't think you'll please everyone here, but even without the 
> compatibility implications, I'm not convinced that moving to unchecked 
> exceptions would be an improvement.
>

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.

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).

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.

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.

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.

Leigh.

_______________________________________________
To control your jdom-interest membership:
http://www.jdom.org/mailman/options/jdom-interest/[email protected]