Java 7 -> Java8 code breakage scenarios

[Maurizio Cimadamore]

On 28/02/13 15:54, Maurizio Cimadamore wrote:
> On 28/02/13 15:45, Boaz Nahum wrote:
>> Great. So just notify me.
>> Boaz
> Fix pushed. ;-)
>
Btw - to clarify; the fix doesn't remove the need for the extra 
dependency - but it allows the compiler to fail gracefully with the 
'class file for XYZ not found' message.

Maurizio

> Maurizio
>>
>>
>> On Thu, Feb 28, 2013 at 5:40 PM, Maurizio Cimadamore 
>> <maurizio.cimadamore at oracle.com 
>> <mailto: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
>>         <mailto: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
>>
>>
>>
>