I'd like to compile an XSLT (a linked set of XSLT documents) to a single
file that will run faster, and will be run directly be the Java runtime
The latter point would, on the user side, avoid dependence on a specific
XSLT processor, but would probably make the file quite large: at least
parts of Saxon's functionality would have to be compiled in, and the
saxon7.jar is 728KB.
But if speed would be faster than with the raw XSLTs, then I wouldn't
mind the added ~meg.
"The term "compile" is stretching a point. The executable that is
produced does not contain machine instructions, or even interpreted Java
bytecode. It contains instructions in the form of a data structure that
Saxon itself can interpret. Note that the format of compiled stylesheets
is unlikely to be stable from one Saxon release to the next."
Perhaps it would be a useful option to compile to Java bytecode. Then
when I distribute the .jar (with XSLT sources), people can run it on
their XML, and all they need is a recent JRE, which they most likely
already have. The .jar would not depend on one specific XSLT processor,
but instead on none (since itself contains some of the required
"Gregor/XSLT compiles W3C standard XSLT transformations (stylesheets)
into Java bytecode classes: translets.
* The translets are optimized for speed and low memory consumption
* They run almost anywhere Java can be run: from servers to pocket sized
* They do not require the presence of an XSLT processor but instead a
small and algorithmically highly optimized runtime library
* Gregor translets can run within applets or servlets
* Sets of translets can be packaged into self-contained executable jars"
"The [...] stylesheets [...] have been compiled with Gregor and packaged
together with Gregor runtime support to form a single, self-contained,
executable Java JAR file. [...] The package runs on any Java (Personal
Profile and above) system, including handhelds [...]"
What do you think?