# 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.

The `SequenceIterator` specification has been tightened-up to define the results returned by the `current()` and `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 `SequenceIterator` 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 `SingletonIterator` returning the same result irrespective of the state of the iterator. This is no longer the case: before `next()` is called for the first time, and after `next()` is called for the second time, the `current()` 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` class.

A user-defined `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 `StaticQueryContext` 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 `XQueryExpression` object.

The API for defining extension instructions in XSLT has changed slightly: various methods are now defined to throw an `XPathException` rather than a `TransformerConfigurationException`. 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 `TransformerConfigurationException`.

Next