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

Thu Apr 15 08:12:00 GMT 2004

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.