Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

NEW BUG: JavaExensionLibrary for Object args

Help
2004-11-15
2012-10-08
  • Major bummer!

    Michael, there's a big new problem in your refactored JavaExtensionLibrary code. Try the following testcase:

    <?xml version="1.0" encoding="UTF-8"?>
    <xsl:transform version="1.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xmlns:w="java:java.io.Writer"
    xmlns:pw="java:java.io.PrintWriter">

    <xsl:template match="/">
    <xsl:variable name="w" select="w:new()"/>
    <xsl:variable name="pw" select="pw:new($w)"/>
    <xsl:value-of select="$pw"/>
    </xsl:template>

    </xsl:transform>

    which results in:

    Error on line 9 of file:/C:/cygwin/home/gunther/xsltgui/bug.xsl:
    Cannot find a matching 1-argument function named {java:java.io.PrintWriter}new
    ()

    PrintWriter's constructors needs the Writer argument. But the static type comparison algorithm never finds that the class of $w indeed matches this.

    I have traced the getConversionPreference code and found that it won't even try the atomic case because it thinks that the arg's cardinality allows many! The arg is statically a variable reference, but
    that doesn't even matter!

    See, even if the expression is simplified without variable references as:

    <xsl:value-of select="pw:new(w:new())"/>

    I get the same error. This time it doesn't assume cardinality > 1 but still there is never anything that considers the ObjectValue arguments properly.

    I am surprized. No, shocked! Have you abandoned supporting ObjectValue as extension function arguments? What am I missing? Please respond.

    thanks,
    -Gunther

     
    • Michael Kay
      Michael Kay
      2004-11-15

      Firstly, the Writer.new() call should fail because Writer is an abstract class. But this doesn't solve the PrintWriter.new() problem.

      This is failing because there are two single-argument constructors and the code isn't sophisticated enough to distinguish them statically. (The messages when you use -TJ make this clear.) It was a conscious decision to move to static resolution, and this is bound to have some adverse consequences in such cases: the solution is to write your own wrapper methods around the polymorphic library methods.

      Saxon 8.2 will improve on this, by doing better static analysis - the new code works on this example. There are two changes, firstly it delays binding to a polymorphic method until the type analysis has been done, and secondly it performs better type analysis on extension types. I'm sorry this doesn't solve your problem in the short term. The changes are a bit too complex to release separately.

      Michael Kay

       
    • Michael, thanks. Glad you're on top of this. When is release 8.2 due? Never mind the abstract class Writer, replace StringWriter instead.

      -Gunther