Bug report: can't overcome Java method ambiguity in some clear cases

[Attila Szegedi]

Well, as I stare at it, I think this should be ambiguous. Based on JS conversion rules, both methods are applicable, and neither method is more specific than the other. I'd say this worked incidentally in Rhino, because it probably just picked the first signature that matched.

Just convert your Integer argument to String explicitly here, e.g.

	series.methodName(someString, String(someInt))

Alternatively, you can use manual overload resolution:

	series["methodName(String, String)"](someString, someInt)

(It'll actually be faster that way, as it won't have to choose an overload on every invocation)

Attila.

On Oct 9, 2013, at 4:18 PM, Tal Liron <tal.liron at threecrickets.com> wrote:

> Here's a particular exception I got:
> 
> java.lang.NoSuchMethodException: Can't unambiguously select between fixed arity signatures [(java.lang.String, java.lang.String), (int, java.lang.Object)] of the method org.restlet.util.Series.set for argument types [java.lang.String, java.lang.Integer]
>    at jdk.internal.dynalink.beans.OverloadedMethod.throwAmbiguousMethod(OverloadedMethod.java:222)
>    at jdk.nashorn.internal.scripts.Script$http.runScript(component/clients/http.js:12)
>    at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:527)
>    at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:204)
>    at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:367)
>    at com.threecrickets.scripturian.adapter.NashornProgram.execute(NashornProgram.java:83)
>    at com.threecrickets.scripturian.Executable.execute(Executable.java:838)
>    at com.threecrickets.scripturian.service.DocumentService.execute(DocumentService.java:154)
>    at jdk.nashorn.internal.scripts.Script$container._L28$_L63(sincerity/container.js:72)
>    at jdk.nashorn.internal.scripts.Script$container._L28$_L82(sincerity/container.js:108)
>    at jdk.nashorn.internal.scripts.Script$default.runScript(component/default.js:57)
>    at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:527)
>    at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:204)
>    at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:367)
> 
> However, it seems rather clear that the first signature is suitable, with the second argument to be coerced into a string. (This works correctly in Rhino.)