Fwd: [jvm-l] Newly introduced OpenJDK javac bug?

[Ulf Zibis]

Am 09.06.2011 17:26, schrieb Rémi Forax:
> On 06/09/2011 04:52 PM, Robert Fischer wrote:
>> I've been using precisely the pattern that Charlie lays out in some of my code, as well, so I'm 
>> going to have to code around it now. I didn't realize that it was technically ambiguous — it's 
>> really surprising to my intuition, which (I'm now realizing as I think about it) tries to match 
>> arguments left to right, and only drops to varargs if it can't find a match. That intuition is 
>> obviously wrong compared to the spec, but does that mean we have a bug in the spec? What's the 
>> justification for this behavior?
>>
>> For the record, both Scala and Groovy resolve methods more in line with intuition:
>> Groovy > https://gist.github.com/1016878
>> Scala > https://gist.github.com/1016880
>>
>
> Yes, because either in Scala or in Groovy int is a subtype of Object.
> There is no point to make a difference between int and Integer in a dynamic language.

I think, C++ would be the more appropriate language to compare here. Does anybody here know, how C++ 
would solve this problem?

what's about:
     method("str", new Integer(1));
Because Integer can be unboxed to int, there should be an ambiguity too according given rules, which 
feels more weird to me.

The only cases, which are not ambiguous here, seem to be:
     method("str", true);
     method("str", 1.0);
     method("str", 1L);
So allowing the coexistence of those 2 signatures would seem weird too.

IMO, not (un)boxed matches should be valued as "more specific"!

-Ulf