Re: Stallman lamenting that GCJ and ClassPath are still (read: eternally)catching up ...

[Andrew Haley <aph at redhat dot com>]

Alan Eliasen writes:
 > 
 > Cedric Berger wrote:
 > > it is always possible to play with new features by compiling to class using
 > > Sun's javac, and use gcj from there.
 > 
 >    This isn't really true, as we've discussed here before.  If you used
 > generics in your code, gcj will refuse to compile that bytecode because gcj
 > doesn't allow two methods in bytecode with the same signature but two
 > different return types.  That's what the generic compiler turns generic
 > methods into.
 > 
 >    For example, I'd love to be able to compile my "Frink" bytecode (
 > http://futureboy.homeip.net/frinkdocs/ ) to an executable using gcj (say, to
 > link with the gmp libraries for fast numeric calculations,) but I can't.
 > 
 >    This was discussed in the thread:
 > http://gcc.gnu.org/ml/java/2003-10/msg00115.html
 > 
 >    This issue is being tracked in bug 9861 and others.  The name-mangling will
 > have to change in gcj if we ever want to compile bytecode that was compiled
 > with a generic compiler.
 > 
 >    Has there been any progress on this issue?

The new gcj ABI doesn't really need to use C++ name mangling at all.
Symbols for Java methods don't need to be global, and don't need to be
exported.  They can be a random string of characters.

However, there are a few problems.  The most important one is
debuugging: we have to find a way to qualify method symbols for
breakpoints, for example.  Also, CNI symbols need to follow the C++
ABI, but that's less of a problem.

The CNI part of this isn't written yet: it'll require some
modifications to the C++ compiler.

Andrew.