The choice of Java method (...) is ambiguous due to bridge methods

[syskin345]

NativeTest.zip

OK I can't figure this one out.

Please see the attached source and run it with rhino-1.8.0 and commons-text-1.13.0 on your classpath.

A Rhino script tries to call method apply on a org.apache.commons.text.similarity.CosineDistance which is an object implementing an interface which in turn extends yet another interface.

The script throws with a message:

The choice of Java method org.apache.commons.text.similarity.CosineDistance.apply matching JavaScript argument types (string,string) is ambiguous; candidate methods are: 
    class java.lang.Double apply(java.lang.CharSequence,java.lang.CharSequence)
    class java.lang.Object apply(java.lang.Object,java.lang.Object) (EvaluationScript#1)

Due to the interface hierarchy, the CosineDistance.class.getDeclaredMethods() exposes two synthetic bridge methods that are used for type erasure, and one of those methods seems to be involved in this ambiguity.

Here's what I can't figure out: I repeated the exact same interface structure in my class Foo (commented-out), got the same methods, and yet somehow that class does not throw the ambiguity exception.

[rPraml]

Is this related to #1575?

[syskin345]

Is this related to #1575?

I.... can't tell. That PR is for matching the better return type, while I have an exception around equally-ambiguous parameters (I think? they're both different).

Both involve bridge methods, but I am not qualified to tell if that PR fixes my issue.

I would also expect that for my case, method discovery should just filter-out all synthetic methods rather than trying to match their parameters.

[rPraml]

I would also expect that for my case, method discovery should just filter-out all synthetic methods rather than trying to match their parameters.

I'm unsure, if this will not raise new problems. Many of us use some bytecode manipulating frameworks, that create such methods. If we just ignore them, this could lead into "MethodNotFound" errors. Rhino has an algorithm, that builds a weight for each method, which is the best match.

Maybe the algorithm should prefer non-synthetic methods, instead of reporting them as ambiguois.

I can take a look at this in 2-3 weeks.

As a workaround, you may use the extende LC syntax. See:

#1352 (comment)
https://www-archive.mozilla.org/js/liveconnect/lc3_method_overloading.html