eliminate gcjh?

Tue Mar 9 18:34:00 GMT 2004

Tom> Second, can we even tell g++ about Java code in some sensible way?
Tom> For instance, overloading-on-return-type seems hugely problematic. We
Tom> can't rename methods (our current workaround for virtual Java methods
Tom> that happen to have the name of a C++ keyword) due to overloading
Tom> considerations.
Andrew> Why not?
Suppose we have a Java .class file that has one of these bridge
methods. In essence it looks like:
 class foo extends something {
 Object m () { ... }
 String m () { ... }
 }
Now suppose we generate a .h file from this.
If you rename either method, you change either how it overrides
methods in the superclass, or you change how subclass methods override
it. I suppose we could fix this by teaching gcjh to traverse the type
hierarchy to make renaming decisions, that would work. But then you
end up in the weird situation that a change in some superclass can
require rewriting your CNI code, because a method name has magically
changed.
Tom