SAXONICA

Saxon Documentation
Full Contents
About Saxon
Changes in this Release
» | Version 8.9 (2007-02-12)
| Version 8.8 (2006-09-05)
| Version 8.7.3 (2006-06-13)
| Version 8.7.2 (2006-04-19)
| Version 8.7.1 (2006-04-13)
| Version 8.7 (2006-02-24)
| Version 8.6.1 (24 November 2005)
| Version 8.6 (3 November 2005)
| Version 8.5.1 (26 August 2005)
| Version 8.5 (2 August 2005)
| Version 8.4 (4 April 2005)
| Version 8.3 (11 February 2005)
| Version 8.2 (21 December 2004)
| Version 8.1.1 (8 October 2004)
| Version 8.1 (24 September 2004)
| Version 8.0 (1 June 2004)
Conditions of Use
Using XSLT 2.0
Using XQuery
Handling Source Documents
XML Schema Processing
XPath API for Java
Saxon on .NET
Extensibility
Saxon Extensions
Sample Saxon Applications
The Saxon SQL Extension
XSLT Elements
XPath 2.0 Expression Syntax
Function Library
Standards Conformance

# XQuery Java Code Generation

The release introduces the ability to compile a query to Java source code. The facility is available in Saxon-SA, and it applies to the Java platform only.

This is a first release of this capability and it should be treated as a beta release, providing early access for evaluation. Feedback is very welcome. Restrictions include:

- Calls to extension functions (external Java functions) cannot be compiled. This includes calls to the built-in extension functions in the Saxon namespace.

- When the query contains external variables, there is no check that the supplied value conforms to the required type.

- There is very limited support for collations.

- The SequenceType `document-node(element(ABC))` is not supported.

- There is no support for substitution groups in a `schema-element()` SequenceType

- On most run-time errors, no information is provided linking the error to a location in the source query.

- The `saxon:validate-type` pragma is not supported.

- There is no separate compilation of modules: the whole query is compiled into a single Java class (sometimes with one or more inner classes)

- For large queries, it is possible that the generated Java code will exceed Java compiler limits.

It's important to have the right expectations for performance. Very often the query will run twice as fast, but the speed-up factor is quite variable. A great deal of the time is spent in the run-time library, and operations such as parsing, tree navigation, sorting, and serialization benefit very little from compilation. Arithmetic computation, on the other hand, improves a lot (especially when it takes place in a predicate or where condition), and so does function calling. For simple path expressions such as `/a/b/c/d` there is no speed-up at all, but for some queries involving complex recursive function calls the compiled code may be a factor of four or five faster.

It is hoped to extend this capability to XSLT in a subsequent release. Compiling for .NET is still under consideration, as is direct generation of bytecode rather than Java source code.

For more details see Compiling Queries to Java code.

Next