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

[B. Blaser]

On 16/12/2019 16:40, Maurizio Cimadamore wrote:
>> 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."
>
> Note that this applied also to 15.12.2.2 - all the paragraphs
> 15.12.2.2/3/4 - are meant to be applied in sequence - they are literally
> the same logic (esp. the first two), just with a different check context
> (strict vs. loose vs. varargs). So I don't get why you believe that
> 'pertinent to applicability' applies to 15.12.2.2 but not to 15.12.2.3 ?

'pertinent to applicability' applies to both, of course, but in
different ways for method references; 'exact' is the condition
expressed in §15.12.2.2 and 'inferrable' is the requirement for
§15.12.2.3.

Interpreting the JLS otherwise would mean that the inexact method
reference 'HashMap::new' is never pertinent to applicability and thus
the assignment inference of 'broker' should fail too... but currently
'putAll()' is rejected while 'broker=' is still accepted.

The difference between them is that the target type constraint from
'Map<? extends Integer, ? extends Integer>' is added during the
overload inference of 'putAll()' in which [1] applies whereas the same
constraint is added during the assignment inference of 'broker=' for
which [2] applies.

On 16/12/2019 16:59, Maurizio Cimadamore wrote:
> Now, the target type here is a wildcard-parameterized type (first
> bullet), so eager instantiation should not happen - but I wonder what
> happens inside javac.

I'm not sure you're looking at the right place, recall that 'putAll()'
works and 'broker=' doesn't with exactly the same argument
'HashMap::new' and the same target type 'Map<? extends Integer, ?
extends Integer>'; the only difference being the overload [1] vs
assignment inference [2] which don't seem to be distinct cases in the
JLS, isn't it?

On Mon, 16 Dec 2019 at 19:42, Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> wrote:
> So, this is not an issue, in the compiler sense (and should be closed).
> Whether there's room to do better in the spec (esp. in terms of
> incorporation) I'll leave that to Dan.

I'm still not sure whether this is a spec or compiler issue (or
nothing), so let's wait for Dan's feedback before closing it.

Cheers,
Bernard

[1] http://hg.openjdk.java.net/jdk/jdk/file/cec148db7b55/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java#l1255
[2] http://hg.openjdk.java.net/jdk/jdk/file/cec148db7b55/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java#l1145