Java 7 -> Java8 code breakage scenarios

[Boaz Nahum]

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.

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
>