Migrating to the XL-TXE-J

From Version 6, the XL TXE-J compiler replaces the XSLT4J interpreter as the default XSLT processor. If you are migrating applications from older versions of Java, follow these steps to prepare your application for the new library.

About this task

The XL TXE-J compiler is faster than the XSLT4J interpreter when you are applying the same transformation more than once. If you perform each individual transformation only once, the XL TXE-J compiler is slower than the XSLT4J interpreter because compilation and optimization reduce performance.

To continue using the XSLT4J interpreter as your XSLT processor, set the javax.xml.transform.TransformerFactory service provider to org.apache.xalan.processor.TransformerFactoryImpl.

To migrate to the XL-TXE-J compiler, follow the instructions in this task.

Note: The IBM XML implementation is deprecated in IBM® SDK, Java™ Technology Edition, Version 8 and will be replaced by the Oracle XML implementation in a future release.

Procedure

  1. Use com.ibm.xtq.xslt.jaxp.compiler.TransformerFactoryImpl when setting the javax.xml.transform.TransformerFactory service provider.
  2. Regenerate class files generated by the XSLT4J compiler. XL TXE-J cannot execute class files generated by the XSLT4J compiler.
  3. Some methods generated by the compiler might exceed the JVM method size limit, in which case the compiler attempts to split these methods into smaller methods.
    • If the compiler splits the method successfully, you receive the following warning:

      Some generated functions exceeded the JVM method size limit and were automatically split into smaller functions. You might get better performance by manually splitting very large templates into smaller templates, by using the 'splitlimit' option to the Process or Compile command, or by setting the 'https://www.ibm.com/xmlns/prod/xltxe-j/split-limit' transformer factory attribute.

      You can use the compiled classes, but you might get better performance by controlling the split limit manually.
    • If the compiler does not split the method successfully, you receive one of the following exceptions:

      com.ibm.xtq.bcel.generic.ClassGenException: Branch target offset too large for short

      or

      bytecode array size > 65535 at offset=#####

      Try setting the split limit manually, or decreasing the split limit.
    To set the split limit, use the -SPLITLIMIT option when using the Process or Compile commands, or the https://www.ibm.com/xmlns/prod/xltxe-j/split-limit transformer factory attribute when using the transformer factory. The split limit can be between 100 and 2000. When setting the split limit manually, use the highest split limit possible for best performance.
  4. XL TXE-J might need more memory than the XSLT4J compiler. If you are running out of memory or performance seems slow, increase the size of the heap using the -Xmx option.
  5. Migrate your application to use the new attribute keys. The old transformer factory attribute keys are deprecated. The old names are accepted with a warning.
    Table 1. Changes to attribute keys from the XSL4J compiler to the XL TXE-J compiler
    XSL4J compiler attribute XL TXE-J compiler attribute
    translet-name https://www.ibm.com/xmlns/prod/xltxe-j/translet-name
    destination-directory https://www.ibm.com/xmlns/prod/xltxe-j/destination-directory
    package-name https://www.ibm.com/xmlns/prod/xltxe-j/package-name
    jar-name https://www.ibm.com/xmlns/prod/xltxe-j/jar-name
    generate-translet https://www.ibm.com/xmlns/prod/xltxe-j/generate-translet
    auto-translet https://www.ibm.com/xmlns/prod/xltxe-j/auto-translet
    use-classpath https://www.ibm.com/xmlns/prod/xltxe-j/use-classpath
    debug https://www.ibm.com/xmlns/prod/xltxe-j/debug
    indent-number https://www.ibm.com/xmlns/prod/xltxe-j/indent-number
    enable-inlining Obsolete in new compiler
  6. Optional: For best performance, ensure that you are not recompiling XSLT transformations that can be reused.
    Use one of the following methods to reuse compiled transformations:
    • If your stylesheet does not change at run time, compile the stylesheet as part of your build process and put the compiled classes on your classpath. Use the org.apache.xalan.xsltc.cmdline.Compile command to compile the stylesheet and set the https://www.ibm.com/xmlns/prod/xltxe-j/use-classpath transformer factory attribute to true to load the classes from the classpath.
    • If your application will use the same stylesheet during multiple runs, set the https://www.ibm.com/xmlns/prod/xltxe-j/auto-translet transformer factory attribute to true to automatically save the compiled stylesheet to disk for reuse. The compiler will use a compiled stylesheet if it is available, and compile the stylesheet if it is not available or is out-of-date. Use the https://www.ibm.com/xmlns/prod/xltxe-j/destination-directory transformer factory attribute to set the directory used to store compiled stylesheets. By default, compiled stylesheets are stored in the same directory as the stylesheet.
    • If your application is a long-running application that reuses the same stylesheet, use the transformer factory to compile the stylesheet and create a Templates object. You can use the Templates object to create Transformer objects without recompiling the stylesheet. The Transformer objects can also be reused but are not thread-safe.
    • If your application uses each stylesheet just once or a very small number of times, or you are unable to make any of the other changes listed in this step, you might want to continue to use the XSLT4J interpreter by setting the javax.xml.transform.TransformerFactory service provider to org.apache.xalan.processor.TransformerFactoryImpl.