Change in javac handling of anonymous/local classes

[Alex Buckley]

On 2/27/2013 12:33 PM, John Spicer wrote:
> Javac 1.7 has what is a surprising difference from 1.6 with regard to this example:
>
> For example,
>
> abstract class TT {
>     void f1(String s) {}
>     void f1(int i1, int i2) {}
>     // Note: no f2
>     void f3(String s) {}
> }
> abstract class X1 {
>     void f1(int i) {}
>     void f2(int i) {}
>     void f3(int i) {}
>     void bar() {
>         new TT() {
>             {
>                 f1(0); // 1.6 error, 1.7 accepts if TT has > 1 f1, finds X1.f1
>                 f2(0); // 1.6 and 1.7 accept, find X1.f2
>                 f3(0); // 1.6 and 1.7 error, finds TT.f3
>             }
>         };
>     }
> }

We have now determined that:

- the f3(0) invocation is correctly flagged as a compile-time error.

- the f1(0) invocation was incorrectly accepted in 1.7 and is correctly 
flagged as a compile-time error in 1.8. (X1.f1(int) is one of three 
methods called f1 which are visible at the f1(0) invocation, but X1 is 
not to be searched during overload resolution.)

Alex