Re: Bug 9861 and Java 5 Generics

[Andrew Haley <aph at redhat dot com>]

Per Bothner writes:
 > Andrew Haley wrote:
 > > It might be possible to preserve some measure
 > > of binary compatibility by providing aliases that don't encode the
 > > return type.
 > 
 > Could you point to summary of why we need return types?  Is it for
 > generics, or for co-variant return types, or both?

It's for generics.  To be truthful it's for compatibility with the
Java VM spec, which has always distinguished methods that differ only
in the type of the return value.  This never mattered in the past, but
the Java 1.5 compiler now generates methods that differ only by their
return type.

 > If it is for co-variant return types, then C++ supports those, so
 > why can't we use the ABI it uses?  A complication is that we have
 > to handle .class files that contains javac-generated stub methods
 > that implement the JDK mechanism for co-variant return types, but
 > it should be possible to suppress generating code for those
 > methods.  (A further complication is that this has to be done for
 > both the compiler and the interpreter, at least to the extent that
 > we produce compatible vtable and interface tables.)

If there's some way to be compatible with C++ I'm all for it,
especially if it allows us to avoid gdb changes.  My understanding is
that C++ covariant returns are much more restricted, though my
knowledge of this area of C++ is rather skimpy.

 > Either way, if there is a way to provide "binary compatibility by
 > providing aliases that don't encode the return type" that implies
 > the compiler can identity a label that doesn't need the return type
 > encoded.  So why not just leave them out in that case?

I suppose it's possible only to encode the return type in cases where
the compiler can prove there would otherwise be a duplication.  This
would be tricky in the case of inheritance, however.

Andrew.