Project

Profile

Help

Bug #4389

ClassCastException when running EE rather than HE

Added by Ken Holman 10 months ago. Updated 10 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Internals
Sprint/Milestone:
-
Start date:
2019-11-18
Due date:
% Done:

0%

Estimated time:
Legacy ID:
Applies to branch:
9.9, trunk
Fix Committed on Branch:
9.9, trunk
Fixed in Maintenance Release:

Description

While I found this in my first attempt to execute EE and it was with this stylesheet and real data, I see that I can reproduce the problem when executing the stylesheet with bogus input:

~/s/companies/bpc $ java -jar ~/p/xml/xslt/saxon9he/saxon9he.jar -s:skeletonCommenter.xsl -xsl:skeletonCommenter.xsl

~/s/companies/bpc $

~/s/companies/bpc $ java -jar ~/p/xml/xslt/saxon9ee/saxon9ee.jar -s:skeletonCommenter.xsl -xsl:skeletonCommenter.xsl java.lang.ClassCastException: net.sf.saxon.pattern.NodeKindTest cannot be cast to net.sf.saxon.type.BuiltInAtomicType at net.sf.saxon.style.XSLKey.compileDeclaration(XSLKey.java:301) at net.sf.saxon.style.PrincipalStylesheetModule.compile(PrincipalStylesheetModule.java:1235) at net.sf.saxon.style.Compilation.compilePackage(Compilation.java:326) at net.sf.saxon.style.StylesheetModule.loadStylesheet(StylesheetModule.java:222) at net.sf.saxon.style.Compilation.compileSingletonPackage(Compilation.java:107) at net.sf.saxon.s9api.XsltCompiler.compile(XsltCompiler.java:785) at net.sf.saxon.Transform.doTransform(Transform.java:741) at net.sf.saxon.Transform.main(Transform.java:80) Fatal error during transformation: java.lang.ClassCastException: net.sf.saxon.pattern.NodeKindTest cannot be cast to net.sf.saxon.type.BuiltInAtomicType ~/s/companies/bpc $

As a side note, oXygenXML reports a syntax error on line 64:

match="Row[not(c:col(.,'ComponentType')='ABIE')] [not(c:col(.,'BPCML')=('','0'))]"

... but there is nothing wrong that I can see with that expression and I get no static error when running HE as seen above.

I hope this is helpful.

. . . . . Ken

skeletonCommenter.xsl (5.5 KB) skeletonCommenter.xsl Ken Holman, 2019-11-18 02:32
skeletonCommenter.xsl (7.41 KB) skeletonCommenter.xsl Ken Holman, 2019-11-18 04:16

History

#1 Updated by Ken Holman 10 months ago

While I found this in my first attempt to execute EE and it was with this stylesheet and real data, I see that I can reproduce the problem when executing the stylesheet with bogus input:

~/s/companies/bpc $ java -jar ~/p/xml/xslt/saxon9he/saxon9he.jar -s:skeletonCommenter.xsl -xsl:skeletonCommenter.xsl
<?xml version="1.0" encoding="UTF-8"?>~/s/companies/bpc $ 
~/s/companies/bpc $ java -jar ~/p/xml/xslt/saxon9ee/saxon9ee.jar -s:skeletonCommenter.xsl -xsl:skeletonCommenter.xsl
java.lang.ClassCastException: net.sf.saxon.pattern.NodeKindTest cannot be cast to net.sf.saxon.type.BuiltInAtomicType
        at net.sf.saxon.style.XSLKey.compileDeclaration(XSLKey.java:301)
        at net.sf.saxon.style.PrincipalStylesheetModule.compile(PrincipalStylesheetModule.java:1235)
        at net.sf.saxon.style.Compilation.compilePackage(Compilation.java:326)
        at net.sf.saxon.style.StylesheetModule.loadStylesheet(StylesheetModule.java:222)
        at net.sf.saxon.style.Compilation.compileSingletonPackage(Compilation.java:107)
        at net.sf.saxon.s9api.XsltCompiler.compile(XsltCompiler.java:785)
        at net.sf.saxon.Transform.doTransform(Transform.java:741)
        at net.sf.saxon.Transform.main(Transform.java:80)
Fatal error during transformation: java.lang.ClassCastException: net.sf.saxon.pattern.NodeKindTest cannot be cast to net.sf.saxon.type.BuiltInAtomicType
~/s/companies/bpc $ 

As a side note, oXygenXML reports a syntax error on line 64:

         match="Row[not(c:col(.,'ComponentType')='ABIE')]
                   [not(c:col(.,'BPCML')=('','0'))]"

... but there is nothing wrong that I can see with that expression and I get no static error when running HE as seen above. I'll report this to the oXygen folks.

I hope this is helpful.

. . . . . Ken

#2 Updated by Ken Holman 10 months ago

p.s. the stylesheet is not near complete and is the midst of being transformed from one approach to a different approach and so there is a mix of text and XML comments ... please don't judge the quality of the stylesheet writing from the incomplete work that you see. If I get a better version done before bed time then I'll post it.

I wanted to post the incomplete stylesheet in case the completed stylesheet does not trigger the exception.

#3 Updated by Ken Holman 10 months ago

Same result with a more complete stylesheet (attached):

~/s/companies/bpc $ java -jar ~/p/xml/xslt/saxon9he/saxon9he.jar -s:skeletonCommenter.xsl -xsl:skeletonCommenter.xsl
~/s/companies/bpc $ java -jar ~/p/xml/xslt/saxon9ee/saxon9ee.jar -s:skeletonCommenter.xsl -xsl:skeletonCommenter.xsl
java.lang.ClassCastException: net.sf.saxon.pattern.NodeKindTest cannot be cast to net.sf.saxon.type.BuiltInAtomicType
        at net.sf.saxon.style.XSLKey.compileDeclaration(XSLKey.java:301)
        at net.sf.saxon.style.PrincipalStylesheetModule.compile(PrincipalStylesheetModule.java:1235)
        at net.sf.saxon.style.Compilation.compilePackage(Compilation.java:326)
        at net.sf.saxon.style.StylesheetModule.loadStylesheet(StylesheetModule.java:222)
        at net.sf.saxon.style.Compilation.compileSingletonPackage(Compilation.java:107)
        at net.sf.saxon.s9api.XsltCompiler.compile(XsltCompiler.java:785)
        at net.sf.saxon.Transform.doTransform(Transform.java:741)
        at net.sf.saxon.Transform.main(Transform.java:80)
Fatal error during transformation: java.lang.ClassCastException: net.sf.saxon.pattern.NodeKindTest cannot be cast to net.sf.saxon.type.BuiltInAtomicType
~/s/companies/bpc $ 

I hope this helps.

. . . . . Ken

#4 Updated by Michael Kay 10 months ago

  • Category set to Internals
  • Status changed from New to In Progress
  • Assignee set to Michael Kay
  • Applies to branch trunk added

I've reproduced the problem and am investigating.

The function call in the use expression has been inlined by the optimizer, and for some reason this has dropped the atomization that was added during type-checking, leading to an unexpected type later.

#5 Updated by Michael Kay 10 months ago

I think the problem is that the c:col function has been inlined before it has been type-checked. The type-checking is responsible for adding the atomization (defined by the return type xs:string of the function) and once inlining has happened, the required type is lost.

Normally we take care to type-check everything before we optimize anything. But it seems that keys are being optmized before functions have been type-checked.

The order of events is controlled in PrincipalStylesheetModule.compile(). There are explicit comments there about the need to type-check functions before inlining them, but the policy has not been followed in the case of key definitions.

#6 Updated by Michael Kay 10 months ago

  • Status changed from In Progress to Resolved
  • Priority changed from Low to Normal
  • Fix Committed on Branch 9.9, trunk added

Solved the problem by moving the call on use.optimize() out of XSLKey.compileDeclaration() and into XSLKey.optimize().

#7 Updated by O'Neil Delpratt 10 months ago

  • Status changed from Resolved to Closed
  • Fixed in Maintenance Release 9.9.1.6 added

Patch committed to the Saxon 9.9.1.6 maintenance release.

Please register to edit this issue

Also available in: Atom PDF