jc1 and different vm langauges

Jakob Praher jp@hapra.at
Sat Mar 11 20:47:00 GMT 2006


hi all,

I am a big fan of different langauges targeting the java bytecode.
With the advent of ecj as a frontend to jc1, jc1 - in my opionion - is
getting more a general purpose java bytecode compiler than a java source
compiler.

Currently though, jc1 has a problem with differenting methods only by
return type. This is not allowed in Java the language, but something like:

Class X {
int foo( );
double foo( );
}

are two valid method defintinos in the class file, cause the signature
also contains the return type. Whereas the gcc C++/Java name mangling
does not.

NameAndType: foo ()I;
NameAndType: foo ()D;

In C++ Name mangling is the same:

_ZN1X3fooE1
_ZN1X3fooE1

In my opinion this is a somewhat philosophical debate. On the one hand
it is handy to have jc1 produce a subset of C++. On the other hand it
leaves out some languages that use that sort of code for internal purposes.

But I want to stress the "internal" purpose. If these methods are only
used within that language, we could in theory add a switch, which would
allow such functionality:

 -fmangle-return-type
 -fmangle-return-type-for=FQCN1,FQCN2,FQPN1,...

My naive algorithm would look like that:

jc1 has the tree method declaration/references availabe and mangles this
in java/mangle.c, so one could check the target .class file, if this
method is only different in terms of the return type, with another method.
        If the -fmangle-return-types switch is not on, the compiler
would generate an error[1].
        Otherwise gcj would generate unique names for these methods. For
instance appending a value of RT<length( )>MangledTypeNameE1.

Wouldn't be there the problem with the C++ mangling scheme, I would not
raise this little problem in the list. But on the other hand, this
change would need common consesus, since there is no support for it in
C++ right now.


[1] - Generating an error is not the case now, gcj simple generates
multiple symbols of the same name. This causes the error to be
propagated to the assembler, which complains in a cryptic way.

-- Jakob



More information about the Java mailing list