SAXONICA

Saxon Documentation
Full Contents
About Saxon
Changes in this Release
Notices
Using XSLT 2.0
Using XQuery
Handling Source Documents
XML Schema Processing
XPath API for Java
Saxon on .NET
Extensibility
| Introduction
» | Writing extension functions in Java
| Converting Arguments to Java Extension Functions
| Converting the Result of a Java Extension Function
| Writing extension functions for .NET
| Converting Arguments to .NET Extension Functions
| Converting the Result of a .NET Extension Function
| Writing XSLT extension instructions
| Customizing Serialization
| Implementing a collating sequence
| Localizing numbers and dates
| Adding an output encoding
| Writing a URI Resolver for Input Files
| Writing a URI Resolver for Output Files
Saxon Extensions
Sample Saxon Applications
The Saxon SQL Extension
XSLT Elements
XPath 2.0 Expression Syntax
Function Library
Standards Conformance

# Writing extension functions in Java

Extension functions may be implemented in Java.

Java extension functions can also be used when you are running on the .NET platform, provided the class implementing the function is a standard class in the GNU Classpath library (which covers nearly all the classes defined in the JDK). In other cases, you should compile the Java code into a .NET assembly using the IKVMC compiler, in which case it behaves in the same way as an extension function written in any other .NET language and compiled into CIL: see Writing extension functions under .NET

An extension function is invoked using a name such as `prefix:localname()`. The prefix must be the prefix associated with a namespace declaration that is in scope. The namespace URI is used to identify a Java class, and the local name is used to identify a method, field, or constructor within the class.

The command line option -TJ is useful for debugging the loading of Java extensions. It gives detailed information about the methods that are examined for a possible match.

There are various ways a mapping from URIs to Java classes can be established. The simplest is to use a URI that identifies the Java class explicitly. The namespace URI should be "java:" followed by the fully-qualified class name (for example `xmlns:date="java:java.util.Date"`). The class must be on the classpath.

For compatibility with other products and previous Saxon releases, Saxon in XSLT only also supports certain other formats of URI. The URI may be a string containing a "/", in which the fully-qualified class name appears after the final "/". (for example `xmlns:date="http://www.jclark.com/xt/java/java.util.Date"`). The part of the URI before the final "/" is immaterial. The format `xmlns:date="java.util.Date"` is also supported.

The Saxon namespace URI `http://saxon.sf.net/` is recognised as a special case. In most cases it causes the function to be loaded from the class `net.sf.saxon.functions.Extensions` but in a few cases, such as `saxon:evaluate`, the function is recognized by the compiler as if it were a built-in function. The various EXSLT namespaces are also recognized specially.

In XSLT it is also possible to set up a mapping from a URI to a Java class using a `saxon:script` declaration in the stylesheet. This declaration can also name a Java archive, which means the class does not have to be on the classpath. The `saxon:script` mechanism is not widely used and may be withdrawn in a future release.

The rest of this section considers how a Java method, field, or constructor is identified. This decision (called binding) is always made at the time the XPath expression is compiled. (In previous Saxon releases it was sometimes delayed until the actual argument values were known at run-time).

There are three cases to consider: static methods, constructors, and instance-level methods. In addition, a public field in a class is treated as if it were a zero-argument method, so public static fields can be accessed in the same way as public static methods, and public instance-level fields in the same way as instance-level methods.

- Calling Static Methods in a Java Class

- Calling Java Constructors

- Calling Java Instance-Level Methods

Next