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

[B. Blaser]

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?
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'?
Bernard