Bug #2573
closed
IncompatibleClassChangeError from bytecode implementing for-each-group()
Category:
Byte code generation
Fix Committed on Branch:
9.7
Fixed in Maintenance Release:
Files
a.xml (274 Bytes)
a.xml |
|
Vinit Varghese, 2016-01-07 01:07
|
|
a.xsl (910 Bytes)
a.xsl |
Sample XSL |
Vinit Varghese, 2016-01-07 01:07
|
|
- Category set to Byte code generation
- Status changed from New to In Progress
- Assignee set to Michael Kay
- Priority changed from Low to Normal
- Applies to branch 9.7 added
Thanks for reporting it. I have reproduced the problem, and have confirmed that it goes away if bytecode generation is disabled (which provides a workaround).
- Subject changed from xsl:sort inside for-each-group() to IncompatibleClassChangeError from bytecode implementing for-each-group()
- Status changed from In Progress to Resolved
- Fix Committed on Branch 9.7 added
The problem has been fixed by a simple patch to ForEachGroupCompiler. It is another instance of a common bug that arose after we refactored Expression to no longer implement Location, but instead to have a getLocation method: in some cases IntelliJ's automatic refactoring added a getLocation() call inappropriately. In most cases Java's static typing detected this, but when it happened in bytecode generation the error is generally at execution time.
What's interesting now is the fact that this went undetected. A supplementary answer on the original StackOverflow report shows that the problem goes away if a call to current-grouping-key() is added to the stylesheet. It turns out that the expression implementing current-grouping-key() is not capable of generating bytecode, and the same is true for current-group(), which means that in nearly all cases the attempt to generate bytecode for an xsl:for-each-group instruction fails. The failure is silent and results in fallback to interpreted execution, which is why none of our tests picked up this issue.
I'm going to mark this issue as solved, and raise a new issue on the fact that bytecode isn't being generated for these function calls.
- % Done changed from 0 to 100
- Fixed in Maintenance Release 9.7.0.2 added
Bug fix applied in the Saxon 9.7.0.2 maintenance release
- Status changed from Resolved to Closed
Please register to edit this issue
Also available in: Atom
PDF