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

[Maurizio Cimadamore]

On 16/12/2019 15:09, B. Blaser wrote:
> On Mon, 16 Dec 2019 at 15:00, Maurizio Cimadamore
> <maurizio.cimadamore at oracle.com> wrote:
>>
>> On 14/12/2019 14:14, B. Blaser wrote:
>>> Thanks for your feedback, Maurizio.
>>>
>>> Using a lacunal inference mechanism during overload resolution would
>>> definitely lead to inconsistencies like this.
>>>
>>> Moreover, JLS §15.12.2.2 [1] is about applicability by strict
>>> invocation and our example refers to applicability by loose invocation
>>> (§15.12.2.3 [2]):
>>>
>>> "If m is a generic method and the method invocation does not provide
>>> explicit type arguments, then the applicability of the method is
>>> inferred as specified in §18.5.1."
>> Same process applies - the subsequent sections e.g. 15.12.2.3 are only applied when previous steps have failed:
>>
>> "If no method applicable by strict invocation is found, the search for applicable methods continues with phase 2 (§15.12.2.3)." - so the pertinent to applicability analysis is really the same for all steps.
> Well, if I apply these rules to our example, javac shouldn't find any
> applicable method by strict invocation (§15.12.2.2) but it should then
> find one by loose invocation (§15.12.2.3) inferring it correctly.

How can it infer it correctly in 15.12.2.3? The arguments are still not 
pertinent to applicability - hence, you will end up with same result 
(lack of constraints).


> The current behavior is a dubious mixture of these two steps; instead
> of performing a clear strict invocation applicability check, javac
> simply truncate the inference process concluding to the
> non-applicability of the candidate.
>
> Of course, this is only my modest interpretation of the JLS.
> So, would you like me to close it as "not an issue"?

Sure, unless I'm missing something of what you are trying to say above.

Maurizio

> Thanks,
> Bernard