JDK-8219318 (???): inferred type does not conform to upper bound(s) when collecting to a HashMap

[Maurizio Cimadamore]

On 18/12/2019 15:35, B. Blaser wrote:
> On Wed, 18 Dec 2019 at 14:59, Maurizio Cimadamore
> <maurizio.cimadamore at oracle.com> wrote:
>>
>> On 18/12/2019 12:24, B. Blaser wrote:
>>> On Tue, 17 Dec 2019 at 22:21, Maurizio Cimadamore
>>> <maurizio.cimadamore at oracle.com> wrote:
>>>> On 17/12/2019 18:22, B. Blaser wrote:
>>>>> Note that the fix I suggested isn't fully symmetric neither; the
>>>>> overload inference would only includes method references that don't
>>>>> have stuck variables, see [1]. The only thing that would have to
>>>>> change in the JLS is that inexact method references with no stuck
>>>>> variables would be pertinent to applicability.
>>>> I'm afraid it can't be that simple - if you have multiple, non-generic
>>>> methods which can be potential target of a method reference expression,
>>>> which one would you use in order to type-check against the functional
>>>> interface target?
>>> On spec side, grosso modo the most specific one or do you mean on javac side?
>> I meant spec side.
>>
>> What if there's no most specific?
>>
>> e.g.
>>
>> m(int)
>>
>> m(String)
> In this case, only one of them can be a potential target (not both), isn't it?

Sure - but if it's pertinent to applicability, you need to chose one to 
rule out some outer overload candidate - e.g.

g(this::m)

Which 'g' gets selected depends on which 'm' you believe the inexact 
reference should resolve to. It's a chicken and egg problem :-)

> Another possibility would be to reduce the fix to 'inexact method
> references with *a unique potential target* and no stuck variables
> would be pertinent to applicability'?

I honestly believe you are looking in the wrong place. I think there's a 
reason (as I explained) as to why pertinent to applicability was defined 
the way it was. If there's a spec problem here, it seems like it lies in 
how incorporation fails to generate constraints for the underconstrained 
vars because of the presence of wildcards. That's a much more direct 
problem to fix, which doesn't involve re-architecting how overload 
selection is structured (which is not gonna happen).

Maurizio

> Bernard