Java 7 -> Java8 code breakage scenarios

[Maurizio Cimadamore]

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
>>