Re: suggested JDOM2 improvements

On 01/20/2012 05:56 AM, Rolf Lear wrote:
> 2. new JDOM2 XPathFactory concept which can have different 
> implementationback-ends (Jaxen, Saxon, whatever).
+1
>
> 3. XPathFactories are thread-safe and reusable in any threads.
>
+1
>
> 4. have a single 'default' XPathFactory instance obtainable with
> XPathFactory.instance(). The default back-end instance() can be changed
> with a system property.
>
This is causing me trouble at the moment.  I have to override the 
XPathFactory, to provide common function definitions and to avoid 
performance problems that Java classlibrary and JAXP cause.  In JDOM1 I 
do this in a static class:
public class JDOMUtil {
   static {
     try {
       XPath.setXPathClass(JaxenXPath.class);
     } catch (JDOMException e) {
       throw new RuntimeException(e);
     }
}

I can be assured that it works, and though I'm not sure under what 
conditions it throws a checked exception, if it does throw one, it's a 
system startup failure to be debugged by a system engineer.

With JDOM 2 alpha I have to do this

// replaced with -Dorg.jdom2.xpath.XPathFactory=com.example.jaxen.JaxenXPath
   static {
     if 
(!(JaxenXPath.class.getName().equals(System.getProperty(JDOMConstants.JDOM2_PROPERTY_XPATH_FACTORY)))) 
{
       throw new RuntimeException(String.format("JDOM Not set up 
property with -D%=%", JDOMConstants.JDOM2_PROPERTY_XPATH_FACTORY,
                                                
JaxenXPath.class.getName()));
     }
   }

Now I've got JDOM2 dependencies off in a faraway place of Java CLI, 
where they can easily get lost.
> 6. Other back-ends can be used at will by calling the
> XPathFactory.newInstance(String) method (or some direct constructor on 
> the
> Factory if it exposes one). 
This doesn't help me fix the above problem, because all of the 
ThreadLocal cache logic and pretty entrypoints into the XPath class 
itself are hardwired to use the System-property defined constructor.  So 
they might as well not be there.

> 5. the default 'default' back-end will continue to be Jaxen
>

Personally, I'd prefer it if you broke this requirement up into a few 
parts and made it easy to have a Jaxen backend.
For example, you might say that there's no XPath support without also 
loading jdom2.jar and jdom2-jaxen.jar.
Right now, with Jaxen having JDOM1 support built in, and then JDOM2 
having Jaxen support built in, it causes a bit of circular confusion 
trying to get things to work.

If we could configure JDOM to use Saxon and have it get good performance 
without unnecessary recalculations, we'd not even load Jaxen all.

Leigh.

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