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