The interface to the
ValidationManager used to control schema validation has
changed slightly, in particular the way that errors are notified to an
application-supplied callback. The aim of this change is to reduce the use of Java
exceptions for handling validation errors, which can be very expensive. The class still
getErrorListener methods, but
are preferred because they avoid creating exceptions (
ErrorListener is a
JAXP-defined interface that requires all error information to be wrapped in exceptions,
even though the exception is never thrown). The method
available but the type of the list that is passed as an argument has changed, again to
avoid use of exceptions.
Methods have been added to XsltCompiler and Xslt30Transformer to enable and disable assertions. At compile time, assertions are disabled by default, but can be enabled (selectively, by package) where required. At run time, assertions are enabled by default provided they were enabled at compile time, but they can be disabled globally.
In previous releases it was possible to pass a tree with schema-validated nodes to an XPath processor not declared as schema-aware. In many cases this would work, but in a few cases it could cause unpredictable failures. To prevent such errors, there is now a check that schema-validated trees cannot be processed by an XPath (or XQuery or XSLT) processor that has not been set to be schema-aware.
In previous releases the
XPathCompiler.compile() method reported static
errors in the supplied expression not only by throwing an exception, but also by
reporting the error to any global
ErrorListener associated with the
Processor. The default
ErrorListener writes messages to the
standard error output. This undocumented behaviour has been changed: the error is now
reported only by means of an exception. Note that for complex XPath expressions there
may be additional information in the exception object beyond the simple error
Serializer object has a new method
returns a SAX
ContentHandler that can be used to feed events into the
This makes it easy to use a s9api
Serializer at the end of a SAX pipeline, or to simply
Serializer directly to a SAX parser in order to achieve simple transformations
such as indenting.