Java name-mangling

[Mark Mitchell]

Folks --

  I've been looking at the Java name-mangling issues in more detail.

  It's harder than I thought.

  The bottom line is that we need to arrange to share the code in
cp/mangle.c between G++ and Java.  Recoding it for the Java front-end
will be difficult and error-prone.  The substitution semantics used in
the new ABI are challenging, to say the least.  Unfortunately, the
code depends on various aspects of the C++ front-end -- it nees to
know about templates, overloaded operators, and other C++-specific
bits.  Factoring the code will be difficult, and will lead to code
that is considerably less clear.  Turning off substitution would
considerably simplify recoding the stuff for Java -- but it's hard to
figure out when to do that, it's non-trivial to do right, and the
mangled version of C++ objects declared `extern "Java"' will then be
incorrect from the C++ point of view.  It would be much better if
`extern "Java"' did not affect name-mangling in C++.

  Java folks, what are you guys planning with respect to the new ABI
for GCC 3.0?  There are issues with layout as well as name-mangling,
including vtable layout.  We need to form a plan of attack here very
soon -- otherwise we're going to rish shipping 3.0 seriously late, or
shipping it minus a working gcj.  Neither alternative is a good one;
to me, neither is acceptable.

  I'm not happy about this.  Both the C++ folks and Java folks should
have communicated with one-another better, and that's my fault at
least as much as anyone else's.  But now we need to do the best we can
going forward.

  There's also an engineering lesson here.  In the same way that
coding libio to depend on the ABI is making trouble, coding gcj to
depend on the C++ ABI makes for difficulties.  The difficulties are
not a direct result of the dependency -- rather, they're a result of
having the dependency, without sharing the code.  If GCJ directly
utiltized the C++ front-end in some way (either by spitting out C++,
or by using C++ front-end modules), we wouldn't be in this pickle.  Of
course, I don't know how that would work, so I can't really criticize
the design choice.  However, we should see if we can't avoid these
kind of dependencies in the future.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com