Bug #3388
closed![Author: Michael Kay](https://www.gravatar.com/avatar/db6526d63053f09b62e52c2da8b2230a?rating=PG&size=50&default=https%3A%2F%2Fassets.plan.io%2Fimages%2Fdefault_avatar.png)
![Assignee: Michael Kay](https://www.gravatar.com/avatar/db6526d63053f09b62e52c2da8b2230a?rating=PG&size=22&default=https%3A%2F%2Fassets.plan.io%2Fimages%2Fdefault_avatar.png)
Conversion of first argument of call to instance-level external method
100%
Description
See https://saxonica.plan.io/boards/2/topics/6918
The conversion of "ordinary" arguments of reflexive Java extension functions is designed to follow the XPath function conversion rules as closely as possible, with a declared argument type of java.lang.String (say) being treated in the same way as a call to an XPath function with the nearest equivalent XPath type (xs:string?). But this doesn't apply to the first argument, which maps to the object whose method is being invoked. For example, if invoking a non-static method on java.lang.String, atomization is not applied to the supplied value -- instead, if a text node is supplied, it results in a message saying that conversion from text nodes to java.lang.String is not supported.
Updated by Michael Kay about 7 years ago
Note that bug 2328 is relevant. https://saxonica.plan.io/issues/2328
Updated by Michael Kay about 7 years ago
In bug 2328 I wrote:
(a) In the code for JavaExtensionFunctionCall, during the typeCheck method for calls to instance-level functions, if the static type of the expression supplied as the first argument is not JavaExternalObjectType, then a converter is allocated, which uses the standard conversion rules to attempt to convert the value of the supplied argument to an external Java object. This is likely to succeed only for classes such as java.util.List, java.lang.String, java.lang.Double, java.util.Map etc that correspond directly to XDM types.
And indeed that is what the code does. But the code for arguments other than the first goes beyond this: it calls staticTypeCheck() on the supplied argument expression, giving as required type the nearest equivalent XPath type to the declared Java type; and it is this call on staticTypeCheck() that injects the code to do run-time atomization.
Updated by Michael Kay about 7 years ago
I have patched the code to add a call on StaticTypeCheck and have added a unit test to show that when the target type is java.lang.String, a supplied node is now atomized.
Need to do some work on the documentation.
Updated by Michael Kay about 7 years ago
- Status changed from New to Resolved
- Applies to branch 9.8 added
- Fix Committed on Branch 9.8 added
The documentation hasn't caught up with some of the changes in recent releases, so I have updated it, essentially to describe the situations in which conversion follows the standard "function conversion rules" to the "equivalent XPath type" of the declared parameter type (thus allowing conversions such as atomization). It has now been updated.
Updated by O'Neil Delpratt about 7 years ago
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
- Fixed in Maintenance Release 9.8.0.4 added
Bug fix applied in the Saxon 9.8.0.4 maintenance release.
Please register to edit this issue