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

[B. Blaser]

On Mon, 16 Dec 2019 at 16:29, Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> wrote:
>
>
> 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).

So, let's go step by step following the JLS:

1) "15.12.2.2. Phase 1: Identify Matching Arity Methods Applicable by
Strict Invocation"

2) "An argument expression is considered pertinent to applicability
for a potentially applicable method m unless it has one of the
following forms:"

3) "An inexact method reference expression (§15.13.1)."

=> 'HashMap::new' isn't pertinent to applicability by strict invocation.

4) "If no method applicable by strict invocation is found, the search
for applicable methods continues with phase 2 (§15.12.2.3)."

5) "15.12.2.3. Phase 2: Identify Matching Arity Methods Applicable by
Loose Invocation"

6) "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."

=> if the overload inference includes constraints from 'HashMap::new'
as suggested in the fix, the method would be pertinent to
applicability.

Did I miss anything?

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

Up to you to conclude, should I close it?

Thanks,
Bernard