Re: eliminate gcjh?

[Andrew Haley <aph at redhat dot com>]

Tom Tromey writes:
 > >>>>> "Andrew" == Andrew Haley <aph@redhat.com> writes:
 > 
 > Per> C++ has covariant return types.
 > 
 > Andrew> Gosh, so it does.  I didn't know that.
 > 
 > Me neither.  Learn something new about C++ every day :-).
 > 
 > The situation is worse than that for us, actually.  With 1.5 the
 > compiler will have to introduce forwarding methods that differ only in
 > return type.  Both these method definitions will end up in a single
 > .class file.  I'm pretty sure C++ can't handle that... which leaves
 > the question of how to generate .h files from such classes.

My best guess is to use name mangling a la JNI.

 > Andrew> When is anyone going to need to write native covariant methods?
 > 
 > The problem isn't just writing them, it is making calls from CNI code
 > to methods defined in other classes, perhaps classes over which one
 > has no control.  I don't know how frequently we'll run into these
 > situations.

Well, quite.  That was my thought: it's an unusual case.  C++ has
technically had covariant methods for a while, but plenty of C++
compiler apparently don't properly implement them.

 > They're pretty easy to construct, though.
 > 
 > I see two problems with having some subset of Java be visible to CNI:
 > 
 > First, how do we document the subset we support?  My concern is that
 > users will run into unclear situations, or situations where they
 > simply can't do what they need to do.
 > 
 > Second, can we even tell g++ about Java code in some sensible way?
 > For instance, overloading-on-return-type seems hugely problematic.  We
 > can't rename methods (our current workaround for virtual Java methods
 > that happen to have the name of a C++ keyword) due to overloading
 > considerations.

Why not?

Andrew.