Saxon

This certainly looks like a bug, and not one that has previously been encountered. If you can give us the information to reproduce it, we will be very glad to look into it.

Of course, finding a bug like this reduces your confidence in the product. However, 9.4 is now very stable and new bugs are rare.

In fact, I think I can already see where the bug is: there are not many places where there is a cast to BinaryExpression and I have found one that is unsafe. (For my own reference, ForExpression line 426). Nevertheless, a repro test case would be most helpful so we can test any patch.

Thank you for the quick response.

I can not provide the complete script but I did manage to trace down the problem to an expression of the following kind:

for $x at $pos in $y where $pos < 6 return ....

If I remove the "where $pos < 6" clause, the problem disappears.

P.S. :

May I please add here another backward compatibility issue which I encountered (after working around the previous) even though it is does not seem to be a compiler bug?

I experience strange issues with access from xquery scripts to java code when running JUnit tests under Maven. What I get is exceptions of the following kind :

net.sf.saxon.s9api.SaxonApiException: Cannot find a matching 1-argument function named {java:com.travelstoremaker.xxx.SomeClass}someMethod()

The same tests run without problems under the Eclipse test runner and also - both in Eclipse and under Maven with Saxon 9.1.0.7.

Any advice?

(It would probably be better to raise different problems on different threads).

Calls to Java extension functions should work largely unchanged though there have been refinements in the details. The problem may simply be a classpath issue, or it could be that you are not invoking Saxon in a way that activates the Saxon-PE functionality.

If you are running from the command line, use the -TJ option to get diagostics on problems with extension functions.

Sorry about mixing unrelated reports.

I am running Saxon embedded in Java code. It turns out that somehow the license file does not get loaded (specifically under Maven/JUnit) even though it is on the class path. Setting the SAXON_HOME environment variable solves the problem. I will not bother you with this further.

I haven't managed to reproduce this. I can see where the code is wrong, but I can't find a query that causes the incorrect code to be activated; this is basically because it is doing an optimization that appears on the surface to be redundant, as it was already performed elsewhere. You've obviously stumbled on some condition that means it can't be optimized the first time around, but succeeds at the second attempt. In the circumstances I will commit a defensive patch that simply bypasses the optimization code in the conditions where the ClassCastException would occur.

In my experience reproduction is straightforward. I just tried quickly in oXygen 14.2 (with Saxon 9.4.0.6) the following:

let $y := (1,2,3,4) return for $x at $pos in $y where $pos < 3 return $x

and the result was the already mentioned above class cast exception.

Thanks for supplying the repro. This has enabled me to reproduce the problem, which was not quite as I had guessed. I have updated the patch accordingly.

Thank you for the quick fix. Any projections as to when a version with the patch may be published?

No sorry we don't have a projected date at the moment; unfortunately this was reported very soon after 9.4.0.7 went out.

I should have mentioned circumvention: you can work around the problem by changing the query to something like

for $x at $pos in $y[position() < 3]

So the fix is supposed to go to 9.4.0.8 whenever that is published?

Yes, that's the normal process. In fact 9.5 might be released first. (This bug had actually already been fixed, somewhere along the line, in the 9.5 branch).