Java 7 -> Java8 code breakage scenarios

Boaz Nahum boaznahum at gmail.com
Thu Feb 28 07:45:23 PST 2013


Great. So just notify me.
Boaz


On Thu, Feb 28, 2013 at 5:40 PM, Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> On 28/02/13 15:32, Boaz Nahum wrote:
>
>> So can I stop my efforts reproducing 'rank' crash ?
>> Actually I reproduce it, But I'm not able to isolate the case - I can
>> easily build JDK and test it.
>>
>> But if you want me to continue retry - no problem.
>>
> Let's do this. I will soon push a patch for the first crash in Flow. You
> can try if that patch also solves the other failure. That would help
> immensely.
>
> Thanks
> Maurizio
>
>
>> Boaz
>>
>>
>> On Thu, Feb 28, 2013 at 3:46 PM, Maurizio Cimadamore <
>> maurizio.cimadamore at oracle.com**> wrote:
>>
>>  On 28/02/13 13:24, Boaz Nahum wrote:
>>>
>>>  //C.java
>>>>
>>>>   public class C {
>>>>
>>>>>       void test(B b) {
>>>>>           Tester.m(B.n());
>>>>>       }
>>>>> }
>>>>>
>>>>> Which is the very one you got. If you'd be so kind to give me some
>>>>> details
>>>>> about the other stack trace you were getting (Types.rank) so that I can
>>>>> come up with some test case (i.e. what is the code that triggered it).
>>>>>
>>>>> Maurizio
>>>>>
>>>>>   Yes exactly. If you named B.n() instead of inline it in the method
>>>>> call
>>>>>
>>>> then you got 'normal' error message.
>>>> The 'rank' exception - I'm working on it.
>>>>
>>>> Thanks !!!
>>>> Boaz
>>>>
>>>>   I believe I got at the bottom of the issue - when a completion error
>>>>
>>> (i.e. missing classfile) occurs in a nested context (i.e. method call),
>>> the
>>> compiler doesn't always report the error, because of some of the
>>> intricacies associated with lambda type-checking and nested method calls.
>>> Those errors should ALWAYS be reported, as a missing classfile error is a
>>> really bad condition that shouldn't be skipped. The fact that the
>>> compiler
>>> is not reporting them in certain cases lead javac to think that
>>> everything
>>> is ok, so that the subsequent compilation step can be executed - which is
>>> not true. Hence all the spurious crashes.
>>>
>>> Maurizio
>>>
>>>
>


More information about the lambda-dev mailing list