New behavior : java: incompatible types: inferred type does not conform to upper bound(s)

[Brian Goetz]

I don't have an answer, but I'll just point out that it's sort of a 
syntax error to describe a behavior of an in-progress sandboxed 
implementation as a "blocker" :)

On 1/7/2013 4:01 PM, Boaz Nahum wrote:
> Thank.As you see it now, Is there a chance that it won't  be fixed ?I'm
> asking because it is stopper for us - We have too many lines like this.
>
> Thanks
> Boaz
> On Jan 7, 2013 10:59 AM, "Maurizio Cimadamore" <
> maurizio.cimadamore at oracle.com> wrote:
>
>> On 01/01/13 15:34, Boaz Nahum wrote:
>>
>>> Hi.
>>>
>>> Old code is no longer compiled (I built lambda/lambda today 1-1-2013)
>>>
>>> static class F<T> {}
>>>
>>> static <T> T get(F<T> f) {return null;}
>>> F<Integer> fi = new F<>();
>>>
>>>
>>> double d1 = get(fi);
>>>
>>> The last line yields
>>>
>>> java: incompatible types: inferred type does not conform to upper bound(s)
>>>       inferred: java.lang.Integer
>>>       upper bound(s): java.lang.Double,java.lang.**Object
>>>
>> This is a side-effect of some inference improvements we have made; we now
>> wait to see the target type before instantiating method type-parameters,
>> which allows the right thing to happen in cases like:
>>
>> class Cell<X> {
>> Cell(X x) { ... }
>> }
>>
>> Cell<Number> c = new Cell<>(1); //fails with JDK 7
>>
>> I think your example shows there're still some improvements to be made
>> around handling of primitives
>>
>> Maurizio
>>
>>>
>>> Only casting solve the problem:
>>>
>>>           double d1 = (int)get(fi);
>>>           double d1 = (double)get(fi);
>>>
>>>
>>> Happy new year
>>> Boaz
>>>
>>>
>>
>