Saxon » SaxonC

Thanks for reporting this issue. I had a look at the underlying Java code for SaxonC and it is unclear why the EXSLT is not being picked up. We will look investigate it closely next week after the XMLPrague conference

-TJ option with SaxonC EE 12.4.2 gives output like

Looking for method has-same-node in namespace http://exslt.org/sets
Number of actual arguments = 2
Looking in Java class class net.sf.saxon.option.exslt.Sets
Seeking a method with adjusted name hasSameNode
Trying method wait: name does not match
Trying method wait: name does not match
Trying method wait: name does not match
Trying method equals: name does not match
Trying method toString: name does not match
Trying method hashCode: name does not match
Trying method getClass: name does not match
Trying method notify: name does not match
Trying method notifyAll: name does not match
No method or field matching hasSameNode with 2 parameters found in class net.sf.saxon.option.exslt.Sets
Looking for method has-same-node in namespace http://exslt.org/sets

(note that the tried methods all seem to be Object standard methods, no specific methods of the Sets class, perhaps a Reflection shortcoming of Java in GraalVM?)

while SaxonJ EE 12.4 gives e.g.

Looking for method has-same-node in namespace http://exslt.org/sets
Number of actual arguments = 2
Looking in Java class class net.sf.saxon.option.exslt.Sets
Seeking a method with adjusted name hasSameNode
Trying method difference: name does not match
Trying method trailing: name does not match
Trying method intersection: name does not match
Trying method hasSameNode: name matches
Method is static
Method has 2 arguments; expecting 2
Found a candidate method:
    public static boolean net.sf.saxon.option.exslt.Sets.hasSameNode(net.sf.saxon.om.SequenceIterator,net.sf.saxon.om.SequenceIterator) throws net.sf.saxon.trans.XPathException

Thank Martin. Yes I suspect we are missing EXSLT class in the reflection JSON file for Graalvm.

Has this been investigated further or even resolved for 12.5?

GraalVM's static analysis is missing quite a few classes that are loaded dynamically, which the EXSLT functions are (this was also the source of an issue with Windows-1252 encoded files on non-windows platforms).

The only sane way to fix it is to use a GraalVM-provided tracing agent to find all the uses of reflection the static analysis doesn't, by running things that are Java clients of the Saxon codebase using the GraalVM JVM, while the tracing agent is loaded. (The other option is to maintain extremely finicky JSON reflection config by hand, where mistakes can make methods or classes which should be available impossible to call...)

We need to ensure that we're covering all the bases there, which the QT3/XSLT3 and EXPath/EXSLT test suites should do, but we need to rework the way those are run to allow running them in the correct JVM with the tracing agent loaded, along with more investigation of what has been covered. That's too much work to make it into 12.5 at this stage, but we're working on it with the aim of putting into the release after 12.5.

Thanks for the explanation, Matt. Looking forward, nevertheless, to the 12.5 release.

Note that most cases where dynamic loading was a problem have been solved by not using Java reflection to load classes that could be loaded directly. For example, the EXPath Binary and File libraries have been rewritten using the conventions for system functions (and indeed, system functions themselves are no longer dynamically loaded).

The only reasons this hasn't been done for the EXSLT functions are that (a) the code is pretty ancient, (b) they are rarely used, and (c) they have never had a very comprehensive test suite. In other words, they are very much second-class citizens. I don't think too many people would scream if we dropped them -- with one exception, exslt:node-set which is a no-op.