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

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Wed Dec 18 13:59:30 UTC 2019


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)

Maurizio


> Bernard


More information about the compiler-dev mailing list