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

[Tal Liron]

I see your point, but once again I'm very worried about:

1) How much Nashorn diverges from not only Rhino, but also many other 
JVM languages.
2) How much Nashorn diverges, in my humble opinion, from the spirit of 
dynamic languages, which generally prefer to plough through ambiguities 
rather than totally fail.

I guess Nashorn is turning out to be something quite different from what 
some of us have envisioned. I'm confident I'm not the only user who will 
be surprised.

On 10/09/2013 10:45 PM, Attila Szegedi wrote:
> 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.)