Elliot Rusty Harold has an article called "Simple Xalan extension functions
," detailing how the Xalan XSLT processor can invoke almost any method in almost any Java class in the classpath. Doing so can improve performance, provide features like trigonometric functions that aren't available in XSLT. The article covers some of the issues in using Java from XSLT, and some examples of where you'd normally use it.
Extensible Stylesheet Language Transformations (XSLT) is a Turing complete programming language. That means that given enough memory, it can calculate anything a program written in any other programming language can calculate. However, this theoretical ability is often impractical. There are several cases where you may need to write code in a more traditional language rather than XSLT:
This article shows you how to link Java classes to XSLT to perform these sorts of operations. The means by which XSLT invokes Java classes varies from one XSLT processor to the next. This article focuses on the Apache Foundation's popular Xalan XSLT processor.
- External I/O -- For instance, files, databases, or network connections. XSLT has very limited ability to read or write these things.
- External devices -- For instance, Universal Serial Bus (USB) ports or the system clock.
- Advanced math -- XSLT can perform basic arithmetic easily enough, but it doesn't support trigonometry, exponential functions, logarithms, or other more advanced mathematical operators and functions. Although you can implement all of these using the basic operations XSLT does support, such a program would be both unwieldy and slow. Using a language that is designed for such operations dramatically improves both performance and legibility.
One other note about XSLT for the unaware, from the article:
Before you begin writing XSLT extension functions, you need to understand one critical difference between the Java programming language and XSLT. XSLT is a functional language. Among other things, this means that it has no global variables, shares no state between function invocations, and causes no side effects. These characteristics enable compilers and interpreters to perform certain optimizations they couldn't otherwise perform. For instance, because the output of a function is completely determined by its input and its code, you don't need to evaluate a function more than once with the same argument. If foo(2) returns 7 the first time you call it, it will return 7 the second time you call it, and the third, and the thirty-third. Therefore intermediate results can be cached and reused, rather than recalculated.
The Java language is imperative rather than functional: It stores state outside of functions, and functions can have side effects. In Java code, foo(2) may return a different value every time you invoke it.
Today's Xalan (2.8) usually works pretty much as you'd expect. Methods are invoked repeatedly, even with the same arguments, and usually in the most obvious order. However, the Xalan developers plan to more aggressively optimize transforms in the future, and the current situation is very likely to change.
Mixing nonfunctional Java code into a functional language like XSLT runs the risk of violating the XSLT processor's assumptions. For instance, the processor might not recalculate a value when it needs to. It might invoke methods in a different order than you expect. It might even invoke them more or fewer times than you expect. Then again, it might do exactly what you expect. However, there's no promise that it will do so, and even if the extension function works today, it might fail in the next point release when the optimization scheme changes a little.
Message was edited by: firstname.lastname@example.org