overload resolution with inexact method reference

[anna.kozlova at jetbrains.com]

Thanks Maurizio!

Is it the same problem if I change outer calls to be generic methods 
like

<B extends TreeMap<String, Long>> B bar(B t) {}
<B> B bar(B o) {}

?


On 02.02.2015 22:58, Maurizio Cimadamore wrote:
> On 02/02/15 18:16, anna.kozlova at jetbrains.com wrote:
>> Hi,
>>
>> given the code
>>
>> class Test {
>>     {
>>         bar(baz(LinkedHashMap::new));
>>     }
>>
>>     <M extends Map<String, Long>> M baz(Supplier< M> mapSupplier) {
>>         return null;
>>     }
>>
>>     void bar(TreeMap<String, Long> t) {}
>>     void bar(Object o) {}
>> }
>>
>> How javac understands that bar(TreeMap<String, Long>) is not 
>> applicable? Does it calculate the type of baz(LinkedHashMap::new) with 
>> inference and all that stuff for all overloads?
>>
> This is an issue we are aware of - there is currently no
> justification for current behavior, see following javac and spec
> issues:
>
> [1] - https://bugs.openjdk.java.net/browse/JDK-8069545
> [2] - https://bugs.openjdk.java.net/browse/JDK-8069544
>
> It's essentially a leftover from the old, more complex overload
> resolution strategy.
>
> Maurizio
>> Thanks,
>> Anna
>
>
> !DSPAM:35,54cfc8cd104222362839998!