enhanced type-inference

Boaz Nahum boaznahum at gmail.com
Tue Jan 29 06:45:59 PST 2013


Thanks.

Indeed it WORKS !!!
Thanks


On Mon, Jan 28, 2013 at 6:25 PM, Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> This just got fixed - let me know how it works for you
>
> Maurizio
>
>
> On 27/01/13 15:35, Boaz Nahum wrote:
>
>> I hope it is not tool late to remind:
>>
>> The below code is no longer valid in JDK 8:
>>
>>      private interface Key<T> { }
>>
>>      private static class Broker {
>>
>>          <T> T getValue(Key<T> key) {...}
>>      }
>>
>>          Broker broker = new Broker();
>>
>>          Key<Integer> ki = new Key<Integer>() {};
>>
>>         *  // fails with error:
>>
>>           //   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*
>>
>>          double d3 = broker.getValue(ki);
>>
>> I was already explained why the error. With 3M lines of code, we only can
>> wait for it to be fixed - or not.
>>
>> Thanks
>> Boaz
>>
>>
>>
>>
>>
>>
>> On Sun, Jan 27, 2013 at 2:10 PM, Peter Levart <peter.levart at gmail.com
>> >wrote:
>>
>>  Very nice, indeed. Congratulations!
>>>
>>> We now hardly need casts if APIs are written correctly.
>>>
>>> One idea that might make the remaining needed casts more concise, but I
>>> don't know how it would play with this new inference scheme, is a kind
>>> of "diamond cast". For example, to disambiguate two overloaded methods
>>> with interchangeable SAM types used for arguments:
>>>
>>> interface F<P, R> { R apply(P p); }
>>>
>>> interface G<P, R> { R apply(P p); }
>>>
>>> class C {
>>>       void m(F<String, Integer> f);
>>>       void m(G<String, Integer> g);
>>> }
>>>
>>> C c = ...;
>>>
>>> c.m(s -> s.length()); // ambiguous
>>>
>>> c.m((G<String, Integer>) s -> s.length()); // ok, but long
>>> c.m((F<>) s -> s.length()); // concise
>>>
>>>
>>> Regards, Peter
>>>
>>> On 01/25/2013 06:49 PM, Maurizio Cimadamore wrote:
>>>
>>>> Dear lambdackers,
>>>> I've just pushed a patch that enables a more general inference support
>>>> for nested generic method calls/stuck expressions. This scheme has been
>>>> available for a while in lambda-repo (when using the hidden flag
>>>> -XDuseGraphInference), but we have now decided it's time to flip the
>>>> switch and make it the default when using JDK 8. In the past few weeks
>>>> I've been hunting down as many bugs in the new inference scheme as
>>>> possible, in order to provide a smooth transition from the old world to
>>>> the new one. I hope the transition is indeed smooth - but, given the
>>>> nature of the change, I also expect bugs to pop up here and there, so
>>>> please, keep throwing the kitchen sink at javac and report your
>>>> experience back to us; without your valuable feedback and dedication we
>>>> would never have gotten thus far.
>>>>
>>>> Example of things that now work:
>>>>
>>>>        Stream<Integer> si = ...
>>>>        List<Integer> l1 = si.into(new ArrayList<>()); //not really - too
>>>> late for that ;-)
>>>>        List<Integer> l2 = si.collect(toList());
>>>>        List<Integer> l3 = si.collect(toCollection(**ArrayList::new));
>>>>
>>>> Thanks
>>>> Maurizio
>>>>
>>>>
>>>>
>>>
>>>
>


More information about the lambda-dev mailing list