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