xsl:sort inside for-each-group()

Question

For some reason xsl:sort inside a for-each-group is throwing an exception since upgrading to Saxon 9.7.0.1

XML-

<table class="vv">
        <tr><td>woot1</td><td>woot2</td></tr>
        <tr><td>woot1</td><td>woot2</td></tr>
        <tr><td>woot1</td><td>woot2</td></tr>
        <tr><td>woot1</td><td>woot2</td></tr>
</table>

XSL-

<xsl:template match="/">
  <xsl:apply-templates/>
</xsl:template>

<xsl:template match="table[@class='vv']">
    <div class="row">
        <xsl:for-each-group select="tr" group-by="td[1]/text()">
            <xsl:sort/>
            test
        </xsl:for-each-group>
    </div>
</xsl:template>

Error-

Just want to verify if this is a bug in Saxon or something got changed with the way this used to work in XSLT 3.0

I can reproduce the problem with 9.7 EE, but not with PE or HE. Are you also using EE? — Martin Honnen, Jan 06 '16 at 09:31

score 3 · Accepted Answer · answered Jan 06 '16 at 09:28

An IncompatibleClassChangeError generally means that there's a class loaded by the JVM at run-time which is different from the way it looked at compile time. That is, the code was compiled with a classpath that included a different version of some library class from the version that has been loaded at runtime.

Two possible theories to investigate:

(a) In this case, on the face of it, all the classes involved seem to be Saxon classes, so this might suggest that you have more than one version of Saxon on the classpath, and for some reason code is being loaded from both.

(b) On the other hand, I can see right at the bottom of your screenshot, half-cropped, a line which suggests that you are using Saxon-EE with byte-code generation enabled, and this might indicate a bug in the byte-code generation. Try disabling byte-code generation to see if the problem goes away. For example by calling Processor.setConfigurationProperty(FeatureKeys.GENERATE_BYTECODE, false).

If it does turn out to be a bytecode generation bug, please log it at http://saxonica.plan.io, so we can track it properly. We will almost certainly need access to a stylesheet that demonstrates the problem.

Thanks for your response. Just verified that only one Saxon jar is being used in the project. We are checking if byte-code generation is enabled or not. — Vinit, Jan 06 '16 at 18:34
Turns out that we have byte-code generation enabled. This goes away if we disable it. Here is the issue- https://saxonica.plan.io/issues/2573 — Vinit, Jan 07 '16 at 00:12

score 1 · Answer 2 · answered Jan 07 '16 at 01:10

1

I don't think this is a real fix but, Mysteriously enough, you can add a <xsl:value-of select="current-grouping-key()"/> statement in the for-each-group body, and the exception goes away. It can be in a comment.

<xsl:template match="table[@class='vv']" mode="copy">
    <div class="row">
        <xsl:for-each-group select="tr" group-by="td[1]/text()">
            <xsl:sort/>
            <xsl:comment><xsl:value-of select="current-grouping-key()"/></xsl:comment>
           test 
        </xsl:for-each-group>
    </div>
</xsl:template>

answered Jan 07 '16 at 01:10

Caroline S

11
1

1

Not at all mysterious, actually. Tiny changes to a stylesheet can take the optimizer down a completely different path, resulting in substantially different execution plans. This is why we generally need a repro that actually demonstrates the problem, rather than just a code snippet. (Thanks for supplyone one). – Michael Kay Jan 07 '16 at 09:08
Though the reasons in this case turn out to be interesting, and are discussed in the Saxon bug entry. – Michael Kay Jan 07 '16 at 09:36

xsl:sort inside for-each-group()

2 Answers2