Re: eliminate gcjh?

[Tom Tromey <tromey at redhat dot com>]

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