How to set Saxon as the Xslt processor in Java?

Question

This is a simple question, but one I cannot find the answer to. I have an XSLT 2.0 stylesheet that I'm trying to process in Java. It relies on XSL elements from Saxon.

My current class works fine with simple XSLT 1.0, but I'm getting errors about unrecognized elements with my 2.0 XSLT built with Saxon.

I cannot figure out how to tell Java to use Saxon as the processor. I'm using javax.xml.transform in my class. Is this a property I can set? What do I set it to? Thanks!

Edited I figured out how to set the property to use Saxon, but now I'm getting this error.

Provider net.sf.saxon.TransformerFactoryImpl not found

How do I include Saxon in my application?

Grube

Found the problem. I needed to add my Saxon jar to the classpath. I thought it was included with Java. – Grube

As well as having the Saxon JAR on the classpath I would recommend instantiating it explicitly: if your code will only work with Saxon, then use "new net.sf.saxon.TransformerFactoryImpl()" rather than relying on the JAXP classpath search to ensure that it's definitely Saxon that's loaded (and to avoid the cost of the classpath search) – Moulding

Answer 1

There are multiple ways to do this (in order of lookup precedence):

Direct Instantiation

Explicitly instantiate the Saxon factory (with a nod to Michael's comment above):

TransformerFactory fact = new net.sf.saxon.TransformerFactoryImpl()

This approach means that your code is locked into using Saxon at compile time. This can be seen as an advantage (no risk of it running with the wrong processor) or a disadvantage (no opportunity to configure a different processor at execution time - not even Saxon Enterprise Edition).

For Saxon-PE, substitute com.saxonica.config.ProfessionalTransformerFactory. For Saxon-EE, substitute com.saxonica.config.EnterpriseTransformerFactory.

Specify Class Name

Specify the factory class when constructing it:

TransformerFactory fact = TransformerFactory.newInstance(
        "net.sf.saxon.TransformerFactoryImpl", null);

Note: available as of Java 6. The Java 5 version does not have this method.

This approach allows you to choose the processor at execution time, while still avoiding the costs and risks of a classpath search. For example, your application could provide some configuration mechanism to allow it to run with different Saxon editions by choosing between the various Saxon factory classes.

Use System Property

Set the javax.xml.transform.TransformerFactory system property before creating an instance:

System.setProperty("javax.xml.transform.TransformerFactory",    
        "net.sf.saxon.TransformerFactoryImpl");

Or on the command line (line broken for readability):

java -Djavax.xml.transform.TransformerFactory=
        net.sf.saxon.TransformerFactoryImpl YourApp

This approach has the disadvantage that system properties affect the whole Java VM. Setting this property to select Saxon could mean that some other module in the application, which you might not even know about, starts using Saxon instead of Xalan, and that module could fail as a result if it uses Xalan-specific XSLT constructs.

Use Properties File

Create the following file:

JRE/lib/jaxp.properties

With the following contents:

javax.xml.transform.TransformerFactory=net.sf.saxon.TransformerFactoryImpl

This approach has similar consequences to using the system property.

Service Loader

Create the following file in any JAR on the CLASSPATH:

META-INF/services/javax.xml.transform.TransformerFactory

With the following contents:

net.sf.saxon.TransformerFactoryImpl

This approach has the disadvantage that a small change to the classpath could cause the application to run with a different XSLT engine, perhaps one that the application has never been tested with.

Platform Default

If none of the above are done, then the platform default TransformerFactory instance will be loaded. A friendly description of this plugability layer can be found here.

Note that 'platform' here means the Java VM, not the hardware or operating system that it is running on. For all current known Java VMs, the platform default is a version of Xalan (which only supports XSLT 1.0). There is no guarantee that this will always be true of every Java VM in the future.

I'd consider this answer an argument against the Java way of doing things.

Demott

could you please elaborate on your last statement? I thought this was a good way of specifying the implementation to use. – Concealment

@Concealment - It's verbose, confusing, and redundant. I don't think it's necessary to have so many ways to do it. I've looked this up 100 times and of course I still had to look up the exact syntax again to provide this answer. – Demott

Awesome! Method 2 did not work on Java 7, but it worked if I instantiated the class itself. – Iey

It should still be supported in Java 7 docs.oracle.com/javase/7/docs/api/javax/xml/transform/… – Demott

dear lwburk what should be the parameter 'YourApp' in java -Djavax.xml.transform.TransformerFactory= cnet.sf.saxon.TransformerFactoryImpl YourApp – Thanksgiving

The app you're starting – Demott

Answer 2

You can explicitly construct the required Source and Result objects to make sure they are Saxon implementations rather than whatever the default ones are.

Vanillin

Thanks for the reply. How do I do that? – Grube

See the comment of Michael Kay. Normally you use the "standard" API classes but these are free to return "any implementation" that conforms to the API. However, you explicitly want to have SAXON implementations so the best bet is to poor over the SAXON docs and figure out which classes implement the StaX API concepts of Source, Result etc. – Vanillin

Answer 3

I wrote a wrapper around Saxon parser in order to make its use simple, and I called it "EasySaxon": you can find it here, with some code snippet of samples.

Hope it helps.

Francesco

Deepdyed