Java API changes
A process has started of identifying all the Java classes and methods that are considered to form
Saxon's public API. These classes and methods are identified with the tag "since 8.4" in the JavaDoc.
Every effort will be made in the future to avoid gratuitous changes to these interfaces in future releases.
However, there is no absolute guarantee of backwards compatibility, given that the W3C language
specifications are still subject to change.
SequenceIterator specification has been tightened-up to define the results returned
position() methods before the first item has been read,
and after the
next() method has returned null to indicate the end of the sequence. In addition,
it is now specified that further calls on
next() should continue to return null: previously this happened for
some iterators, while others threw an exception. Existing implementations of
have been changed to conform to these tighter rules. There were a number of places in the Saxon code
that relied on the
current() function when applied to a
the same result irrespective of the state of the iterator. This is no longer the case: before
is called for the first time, and after
next() is called for the second time, the
method on a
SingletonIterator now returns null.
In the XQuery API, the
QueryProcessor class, which has been deprecated since Saxon 8.1,
is now withdrawn. All its methods are available on the
StaticQueryContext is no longer modified by Saxon when a query is compiled.
Instead, Saxon makes a copy for its internal use. This means that the same
object may now be used to define multiple queries, in series or in parallel threads. A consequence of this
change is that it is no longer possible to obtain information about the query, for example the names of the
functions that it declares, from the original
StaticQueryContext. However, the modified
copy of the
StaticQueryContext is available via a method on the
The API for defining extension instructions in XSLT has changed slightly: various methods are now defined
to throw an
XPathException rather than a
This change was made to enable error codes to be associated with all error conditions: error codes can be
held in an
XPathException, but not in a