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

[Attila Szegedi]

Fair enough. If someone writes "1.0", it's reasonable to expect they had a floating point in mind. We are probably prematurely "optimizing" the constant 1.0 to an int. I opened <https://bugs.openjdk.java.net/browse/JDK-8026161> to track this.

Attila.

On Oct 9, 2013, at 4:43 PM, Andreas Woess <andreas.woess at jku.at> wrote:

> I'd like to add to this bug report:
> 
> jjs> new java.awt.Color(0.5,0.5,0.5)
> java.awt.Color[r=128,g=128,b=128]
> jjs> new java.awt.Color(1.0,0.5,0.5)
> java.lang.RuntimeException: java.lang.NoSuchMethodException: Can't
> unambiguously select between fixed arity signatures [(float, float,
> float), (int, int, int)] of the method java.awt.Color.<init> for
> argument types [java.lang.Integer, java.lang.Double, java.lang.Double]
> I would have expected an automatic int->float conversion here.
> 
> interestingly enough, this works in Nashorn (but not in Rhino):
> jjs> new java.awt.Color(1.0,0.5)
> java.awt.Color[r=0,g=0,b=1]
> 
> - andreas
> 
> On 09.10.2013 16:18, Tal Liron 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.)
>> 
>