Diamonds: cyclic inference error

[Maurizio Cimadamore]

On 15/10/12 17:52, Remi Forax wrote:
> I'm not sure it's related to lambda,
> I think it's more related to the way the inference works with the
> diamond syntax,
>
> this code doesn't compile:
> static <K,V> Map<K,V> foo(Map<K,V> map) {
>       return map;
> }
> ...
> Map<String, String> map = foo(new HashMap<>());
>
> said differently, the rules introduced with Java 8 fix inference
> introduced with Java 5
> but not the one introduced with Java 7 (it will be fixed in Java 10 if
> future follows the same pattern).
I don't get the cynism here.

Diamond is not the issue - the problem happens with all nested generic 
method calls  where the target type contains one or more inference variable.

Maurizio
>
> Rémi
>
> On 10/15/2012 06:15 PM, Aleksey Shipilev wrote:
>> On 10/15/2012 06:50 PM, Maurizio Cimadamore wrote:
>>>> ...and if I write out the explicit type arguments within the diamond,
>>>> the test compiles well. Is this a spec-ed behavior, or just a bug?
>>> This is the spec'd behavior, yes. You are passing an implicit lambda to
>>> a method where the target type contains inference variables (because of
>>> diamond). Which means javac doesn't know what the lambda parameter types
>>> should be inferred to. Javac would try to delay type-checking of the
>>> lambda expression as much as possible (to see if other inference
>>> constraints can be derived from remaining argument expression) - but in
>>> this case there's no additional arguments. Either you specify the type
>>> of the diamond, or you specify the explicit lambda parameter type.
>> For the record, this one works:
>>
>>           Map<String, Map<String, Counter>> map =
>>                   new ComputeTreeMap<>(
>>                           (String s) -> new ComputeTreeMap<>(
>>                                  (String x) -> new Counter()
>>                           )
>>                   );
>>
>>
>> Thanks,
>> Aleksey.
>>
>