J++ Bugs

I've noticed four bugs that users should be aware of:

1. J++ does not carry over unimplemented abstract methods inherited from one abstract class to a derived abstract class.  The following code example compiles without errors, even though it should not:

   abstract class A
   {
       abstract int a();
       abstract int b();
       abstract int c();
   }
   abstract class B extends A
   {
       int a()
       {
           return 2;
       }
       // The problem is right here: while methods b() and c() should be
       // "inherited abstractly," they are not.  Therefore a class that
       // extends B does not have to implement b() and c().
   }
   class C extends B
   {
       int b()
       {
           return 4;
       }
       // This class should not compile because method c() is not implemented.
       // However, because of the J++ bug, it does.
   }

   Workarounds:

   • Redeclare all of the abstract member functions in the class B.  In other words, put

     abstract int b();
     abstract int c();

     in the definition for class B.

   • Use a different comiler for this class (the JDK compiler handles this fine).
   • Be sure to implement all of the required methods, without relying on the compiler to generate errors where some are unimplemented.
   • Tony has informed me that if the classes are defined in separate files and compiled in the correct order, unimplemented methods correctly generate errors.  The problem was originally observed and tested where all of the classes were in the same file.
2. You cannot hold a final reference to an instance of an internal class, unless that reference is null.  The following code example illustrates:

   class A
   {
       final B b = new B();
       // This does compile, but a build on the whole project will fail (with the infamous
       // "Internal Compiler Error") because we marked variable b to be final.  I guess the
       // compiler has a hard time deciding how to build the constructor for class A because
       // it has to create the instance of B before the instance of A.
       class B
       {
           int a()
           {
               return -2;
           }
       }
   }

   Workarounds:

   • Leave the reference to b as final, but initialize it in the constructor of A.  For example, this is legal and safe:

     final class A
     {
         A()
         {
             b = new B();
         }
         final B b;
         private final class B
         {
             int a()
             {
                 return -2;
             }
         }
     }

   • Make the reference to the instance of the internal class non-final.
   • Use a different compiler for this project (the JDK compiler handles this fine).
   • Make class B non-internal (i.e., define it outside of class A).
3. Apparently you can assign to a final String reference using the += operator, as below:

final String s = "abc";
s += "def";

The JDK compiler rejects this as a syntax error, but J++ compiles it without errors.

4. The compiler thinks an abstract method has not been implemented if a class has a member has the same name as an abstract method it implemented.  For example, the following code does not compile, even though it should:

   abstract class a
   {
       abstract int f();
   }
   class b extends a
   {
       int f()
       {
           return 4;
       }
       private boolean f; // Because we declared this field, J++ thinks
                          // we didn't implement f()
   }

   Workarounds:

   • Use the JDK compiler, which has no problem with this
   • Rename the field, which is probably more feasable than renaming the method
5. You cannot nest anonymous classes, although in the JDK compiler you can.

---

Jonas Gifford, January 14, 2004