eliminate gcjh?

[Tom Tromey]

>>>>> "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.

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.  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.


We've always been cheating a little, in that it was always valid to
have .class files that gcjh and g++ wouldn't make sense of.  This was
ok, though, because java compilers never generated the problematic
code.

Tom