Bug in choosing among overloaded methods

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug in choosing among overloaded methods

Paul Benedict
I am using saxon 8.7 and calling an instance method on a Java object.

This is the error message:
"There is more than one method matching the function call XXX, and there is insufficient type information to determine which one should be used"

But in my case this is incorrect. I have an interface with a single method and a class that implements the interface. Unfortunately, the saxon parser sees these as two identical methods. Only concrete methods should be considered. All abstract methods should be filtered away.

Cheers,
Paul

------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help 
Reply | Threaded
Open this post in threaded view
|

Re: Bug in choosing among overloaded methods

Michael Kay
You will have to be much more specific if you want help with this - like giving the relevant classes/methods and the code that is invoking them; and you will have to show that the problem is present on a more recent release. Saxon 8.7 dates from 2006 and there have been 10 major releases since then.

I don't recall if the -TJ option was available back then - try it and see. It will report what the two matching methods are that it is having trouble choosing between.

Michael Kay
Saxonica

P.S. I've just realised that I would have reacted less negatively to this message if you hadn't started the title "Bug ...", but had instead asked for help. Sorry about that - it's instinctive; but bear it in mind when you ask for help on other forums. There's no prima facie evidence of a bug here. I positively welcome it when people do report real bugs, but only if they supply real evidence.


> On 5 Dec 2015, at 01:34, Paul Benedict <[hidden email]> wrote:
>
> I am using saxon 8.7 and calling an instance method on a Java object.
>
> This is the error message:
> "There is more than one method matching the function call XXX, and there is insufficient type information to determine which one should be used"
>
> But in my case this is incorrect. I have an interface with a single method and a class that implements the interface. Unfortunately, the saxon parser sees these as two identical methods. Only concrete methods should be considered. All abstract methods should be filtered away.
>
> Cheers,
> Paul
> ------------------------------------------------------------------------------
> Go from Idea to Many App Stores Faster with Intel(R) XDK
> Give your users amazing mobile app experiences with Intel(R) XDK.
> Use one codebase in this all-in-one HTML5 development environment.
> Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
> http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140_______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/saxon-help



------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help 
Reply | Threaded
Open this post in threaded view
|

Re: Bug in choosing among overloaded methods

Paul Benedict
On Sat, Dec 5, 2015 at 10:55 AM, Michael Kay <[hidden email]> wrote:
You will have to be much more specific if you want help with this - like giving the relevant classes/methods and the code that is invoking them; and you will have to show that the problem is present on a more recent release. Saxon 8.7 dates from 2006 and there have been 10 major releases since then.

OK. I am using 8.7 because that's the latest I found under the "saxon" Group ID in Maven. However, I now see it's been relocated to "net.sf.saxon" and there is a 9.7.0.1 jar called Saxon-HE. Is that the latest you are referring to?

 
P.S. I've just realised that I would have reacted less negatively to this message if you hadn't started the title "Bug ...", but had instead asked for help. Sorry about that - it's instinctive; but bear it in mind when you ask for help on other forums. There's no prima facie evidence of a bug here. I positively welcome it when people do report real bugs, but only if they supply real evidence.

My apologies for causing a negative reaction. The support page [1] says write to the mailing list to report a bug. So I thought I was following standard procedure.
[1] http://www.saxonica.com/html/support/support.html

How to reproduce it:

package z;
public interface Foo<T> {
  T foo();
}

package z;
public class MyFoo implements Foo<String> {
  String foo() { return "foo"; }
}

XSLT:
<xsl:stylesheet
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  xmlns:z="java:z.MyFoo"
  version="2.0">

  <xsl:variable name="my" select="z:new()" />
  <xsl:value-of select="z:foo($my)" />
 
</xsl:stylesheet> 
 
The problem I deduced was the generics. If you take away the generics, things are fine. I suspect the problem is resolving bridge methods. Perhaps saxon is including bridge methods in its resolution and not understanding they are synthetic.

Cheers,
Paul

------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help 
Reply | Threaded
Open this post in threaded view
|

Re: Bug in choosing among overloaded methods

Michael Kay
I thought this was going to be the standard question about using parameterized types to disambiguate method calls, e.g. passing List<String> vs List<Date> (where we could try to be smarter, but make no attempt to do so), but it seems it's a little different.

It's true that Saxon makes no attempt to exclude synthetic or bridge methods from its search. I was under the impression that synthetic methods always had synthetic names, but I now see that isn't the case.

I've been trying to think whether there might be any legitimate code that breaks if we exclude synthetic methods from the search. I don't think so, but since there's no way of being 100% certain I'm inclined to introduce such a change only for 9.7. Changes to the logic for reflexive extension functions have a nasty habit of backfiring.

As far as I can see if a method is a bridge method then it is always going to be a synthetic method, so we don't need to consider bridge methods separately.


Michael Kay
Saxonica


How to reproduce it:

package z;
public interface Foo<T> {
  T foo();
}

package z;
public class MyFoo implements Foo<String> {
  String foo() { return "foo"; }
}

XSLT:
<xsl:stylesheet
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  xmlns:z="java:z.MyFoo"
  version="2.0">

  <xsl:variable name="my" select="z:new()" />
  <xsl:value-of select="z:foo($my)" />
 
</xsl:stylesheet> 
 
The problem I deduced was the generics. If you take away the generics, things are fine. I suspect the problem is resolving bridge methods. Perhaps saxon is including bridge methods in its resolution and not understanding they are synthetic.



------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help 
Reply | Threaded
Open this post in threaded view
|

Re: Bug in choosing among overloaded methods

Paul Benedict
Thank you Michael. Unfortunately, I just tested upgrading to HE 9.7 and it no longer has the ability to call Java methods like the 8.x series did. That's disappointing that I will not be able to use the fix. In any event, I am happy that you verified the problem and have a patch for your users.

Cheers,
Paul

On Mon, Dec 7, 2015 at 3:34 AM, Michael Kay <[hidden email]> wrote:
I thought this was going to be the standard question about using parameterized types to disambiguate method calls, e.g. passing List<String> vs List<Date> (where we could try to be smarter, but make no attempt to do so), but it seems it's a little different.

It's true that Saxon makes no attempt to exclude synthetic or bridge methods from its search. I was under the impression that synthetic methods always had synthetic names, but I now see that isn't the case.

I've been trying to think whether there might be any legitimate code that breaks if we exclude synthetic methods from the search. I don't think so, but since there's no way of being 100% certain I'm inclined to introduce such a change only for 9.7. Changes to the logic for reflexive extension functions have a nasty habit of backfiring.

As far as I can see if a method is a bridge method then it is always going to be a synthetic method, so we don't need to consider bridge methods separately.


Michael Kay
Saxonica


How to reproduce it:

package z;
public interface Foo<T> {
  T foo();
}

package z;
public class MyFoo implements Foo<String> {
  String foo() { return "foo"; }
}

XSLT:
<xsl:stylesheet
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  xmlns:z="java:z.MyFoo"
  version="2.0">

  <xsl:variable name="my" select="z:new()" />
  <xsl:value-of select="z:foo($my)" />
 
</xsl:stylesheet> 
 
The problem I deduced was the generics. If you take away the generics, things are fine. I suspect the problem is resolving bridge methods. Perhaps saxon is including bridge methods in its resolution and not understanding they are synthetic.



------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help


------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help