Question

I would like to provide diagnostic information about what JAXP implementation is in use, and which JAR file it was loaded from.

One way to achieve this is to create in instance of, for example, a DocumentBuilderFactory, and then inspect the properties of that class:

private static String GetJaxpImplementation() {
    DocumentBuilderFactory documentBuilderFactory = DocumentBuilderFactory.newInstance();
    Class<? extends DocumentBuilderFactory> c = documentBuilderFactory.getClass();
    Package p = c.getPackage();
    CodeSource source = c.getProtectionDomain().getCodeSource();
    return MessageFormat.format(
            "Using JAXP implementation ''{0}'' ({1}) version {2} ({3}){4}",
            p.getName(),
            p.getImplementationVendor(),
            p.getSpecificationVersion(),
            p.getImplementationVersion(),
            source == null ? "." : " loaded from: " + source.getLocation());
}

Is there a better way to achieve this, perhaps without having to create a DocumentBuilderFactory?

Answer 1

It is quite difficult to predict what concrete JAXP factory implementation will be loaded without actually creating an instance because the process for selecting an implementation.

From the Official JAXP FAQ (Question 14):

When an application wants to create a
new JAXP DocumentBuilderFactory
instance, it calls the staic method
DocumentBuilderFactory.newInstance().
This causes a search for the name of a
concrete subclass of
DocumentBuilderFactory using the
following order:

1. The value of a system property like javax.xml.parsers.DocumentBuilderFactory if it exists and is accessible.
2. The contents of the file $JAVA_HOME/jre/lib/jaxp.properties if it exists.
3. The Jar Service Provider discovery mechanism specified in the Jar File Specification. A jar file can have a resource (i.e. an embedded file) such as META-INF/services/javax.xml.parsers.DocumentBuilderFactory containing the name of the concrete class to instantiate.
4. The fallback platform default implementation.

Adding to this complexity, each individual JAXP factory can have an independent implementation specified. It is common to use one parser implementation and another XSLT implementation, but the granularity of the selection mechanism above allows you to mix and match to an even greater degree.

The following code will output information about the four main JAXP factories:

private static void OutputJaxpImplementationInfo() {
    System.out.println(getJaxpImplementationInfo("DocumentBuilderFactory", DocumentBuilderFactory.newInstance().getClass()));
    System.out.println(getJaxpImplementationInfo("XPathFactory", XPathFactory.newInstance().getClass()));
    System.out.println(getJaxpImplementationInfo("TransformerFactory", TransformerFactory.newInstance().getClass()));
    System.out.println(getJaxpImplementationInfo("SAXParserFactory", SAXParserFactory.newInstance().getClass()));
}

private static String getJaxpImplementationInfo(String componentName, Class componentClass) {
    CodeSource source = componentClass.getProtectionDomain().getCodeSource();
    return MessageFormat.format(
            "{0} implementation: {1} loaded from: {2}",
            componentName,
            componentClass.getName(),
            source == null ? "Java Runtime" : source.getLocation());
}

The following sample output illustrates a mix-and-match of three different JAXP implementations (Built-in Xerces and external JARs for Xerces 2.8 and Xalan) working together:

DocumentBuilderFactory implementation: org.apache.xerces.jaxp.DocumentBuilderFactoryImpl loaded from: file:/C:/Projects/Scratch/lib/xerces-2.8.0.jar
XPathFactory implementation: com.sun.org.apache.xpath.internal.jaxp.XPathFactoryImpl loaded from: Java Runtime
TransformerFactory implementation: org.apache.xalan.processor.TransformerFactoryImpl loaded from: file:/C:/Projects/Scratch/lib/xalan.jar
SAXParserFactory implementation: org.apache.xerces.jaxp.SAXParserFactoryImpl loaded from: file:/C:/Projects/Scratch/lib/xerces-2.8.0.jar