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

B. Blaser bsrbnd at gmail.com
Mon Dec 16 15:09:23 UTC 2019


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.
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"?

Thanks,
Bernard


More information about the compiler-dev mailing list