Change in javac handling of anonymous/local classes

[John Spicer]

If I have a question about whether a certain javac behavior is a bug or a feature.

Alex Buckley suggested that this is the appropriate forum for such a question.

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

For anonymous and local classes, javac seems to create an overload set containing both inherited methods from the specified superclass and methods from the enclosing class, but only when the superclass has more than one method with a given name (the f1 case).   If the superclass has exactly one method with that name, only the superclass method is found (the f3 case).   And, of course, if the superclass has no method with that name, the enclosing method is found (the f2 case).

I would expect the f1 and f3 cases to work in the same way.  Javac 1.6 found the inherited method in both the f1 and f3 cases.

There is some kind of javac (1.7) bug here, but it could be in either the handling of the f1 case or the f3 case.   If it is the case that the f3 case should be handled like the f1 case, then it is a JLS and a javac issue (the JLS issue being that there is no merging of inherited members and members of enclosing classes).   If it is the case that that f1 should be handled like f3 then it is only javac issue.

Any guidance on this issue would be appreciated.

John Spicer
Edison Design Group