gcj 4.3 regressions
Brett Kail
bkail@iastate.edu
Mon Feb 19 23:26:00 GMT 2007
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
More information about the Java
mailing list