a '<clinit>' is generated in the output file of gcc whereas it isn't present in the class file. In that case it should not be enumerated as a declared method: this can cause major troubles in the serialization logic of libjava which then fails to produce a valid serialVersionUID. This seems to happen only in the typical case of the following example: public class C { static class D extends C { private static final String s = "hello"; } } If you try to compile this example, it will generate a static '<clinit>' method in the inner class D, which should not happen as the class file doesn't have it.
Confirmed. The problem is that GCJ when generating native from source does create C.D.s really statically, it has to do a store which causes this. When GCC generates from class files to native or to class files, it produces no <clinit> at all, just like Sun's javac.
It isn't clear this is actually a bug. Here's a nice discussion of some of the problems: http://gcc.gnu.org/ml/java-patches/2002-q4/msg00036.html
Okay this is not an ABI bug but it still is a pressimize code generation, there is no need for <clinit>.
More than just that it can cause wrong-code, see PR 1259.
All gcj front end bugs have been fixed by the gcj-eclipse branch merge. I'm mass-closing the affected PRs. If you believe one of these was closed in error, please reopen it with a note explaining why. Thanks.