Re: gcj 4.3 regressions

[Brett Kail <bkail at iastate dot edu>]

Hello,

First, my apologies for breaking threading; I do not know how to set the 
References header manually in Thunderbird.  Second, this note is a 
resend of a private email to Andrew Haley (with a few minor editorial 
corrections) that he requested I send to this mailing list.

I'm a lurker on the gcc-patches mailing list.  I came across this 
message from Andrew:

  http://gcc.gnu.org/ml/gcc-patches/2007-01/msg02011.html
  http://gcc.gnu.org/ml/java-patches/2007-q1/msg00170.html

It references this bug:

  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30574

I believe I can explain this behavior from javac.

The default constructor of a class inherits the visibility of the class 
itself.  Compare "class c {}" and "public class c {}".  It logically 
follows that the visibility of the default constructor of a private 
inner class will be private.  This is not really relevant; the effect is 
the same in the following example, which perhaps makes it easier to 
understand the compiler's choice:

  public class a {
    public a() {
      new b();
    }
    public static class b {
      private b() { }
    }
  }

The outer class must be able to instantiate the inner class.  To 
accomplish this, the compiler creates a synthetic constructor with 
default visibility in the inner class that forwards to the private 
constructor.  In order to create a signature that is guaranteed to be 
unique, the compiler chooses to generate another synthetic inner class 
that it can use to "mark" this synthetic constructor.

Andrew notes in the bug report that ecj does not generate this synthetic 
inner class.  It seems that ecj prefers to modify the constructor to 
have default visibility, but javac prefers to maintain the visibility 
declared by the user whether implicitly, as in Andrew's test case, or 
explicitly, as in the example above.

Hope that helps,
-Brett