The following Generic Java code was compiled to the two classes which can be found in the attachment. // TestGJ.java begins here class Test<Type> { protected Type x () { return null; } } public class TestGJ extends Test<Integer> { protected Integer x () { return new Integer (1); } public static void main (final String[] argv) { new TestGJ ().x ().intValue (); } } // TestGJ.java ends here If you execute "java TestGJ" (adjust CLASSPATH as necessary) the program runs without error (BTW, there is no output). But compilation of the class files with gcj fails because of a name clash during assembly. Release: gcc-3.2.1 Environment: gentoo linux 1.4 gcc version 3.2.1 20021207 (Gentoo Linux 3.2.1-20021207) GNU assembler version 2.13.90.0.18 (i586-pc-linux-gnu) using BFD version 2.13.90.0.18 20030121 How-To-Repeat: If you execute gcj -classpath /usr/share/gcc-data/i586-pc-linux-gnu/3.2/java/libgcj-3.2.1.jar:. Test.class TestGJ.class you should get output similar to /tmp/cc5J7vu9.s: Assembler messages: /tmp/cc5J7vu9.s:150: Error: symbol `_ZN6TestGJ1xEv' is already defined
Fix: The mangled name of a method must contain the method's return type, as in the definition of a method descriptor in the Java Virtual Machine Specification.
State-Changed-From-To: open->analyzed State-Changed-Why: Ouch. I don't see how we can fix this without breaking CNI compatibility with C++.
This requires an ABI change.
It certainly does require an ABI change, but as we're changing the ABI anyway I wouldn't expect a problem. In any case, the BC-ABI that we're working on at the moment will solve this problem. It's CNI that is the stumbling block in this case. I'm adding 12758 as a dependency.
Some useful tips can be found here: http://gcc.gnu.org/ml/java-patches/2005-q2/msg00558.html
I did some work on this. It's not quite ready for prime-time: http://tjlaurenzo.blogspot.com/2005/08/adventures-with-java-5-and-gcj.html I'll try to roll it up into a proper patch and such when I get the suite rebuilt and tested. Since its a breaking ABI change, I imagine the primary audience for this patch in the short term would be people who really need this bug fixed and are willing to give up compatibility to do it.
I have submitted a patch to fix this bug to the gcc-patches mailing list. The URL of the message is: http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01496.html
This was fixed by TJ's patch applied on 2005-12-10.