Java 7 -> Java8 code breakage scenarios

[Maurizio Cimadamore]

On 28/02/13 15:45, Boaz Nahum wrote:
> Great. So just notify me.
> Boaz
Fix pushed. ;-)

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