Build failure with the 0.98 merge

[David Daney]

David Daney wrote:
> Andrew John Hughes wrote:
>> Hi all,
>>
>> I'm getting a build error when trying to compile the version of GCJ
>> merged with Classpath 0.98:
>>
>> In file included from
>> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/interpret.cc:25:
>> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/java/lang/StringBuffer.h:97: 
>>
>> error: 'java::lang::AbstractStringBuffer*
>> java::lang::StringBuffer::StringBuffer$append(jchar)' cannot be
>> overloaded
>> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/java/lang/StringBuffer.h:38: 
>>
>> error: with 'virtual java::lang::StringBuffer*
>> java::lang::StringBuffer::StringBuffer$append(jchar)'
>> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/java/lang/StringBuffer.h:100: 
>>
>> error: 'java::lang::AbstractStringBuffer*
>> java::lang::StringBuffer::StringBuffer$append(java::lang::CharSequence*,
>> jint, jint)' cannot be overloaded
>> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/java/lang/StringBuffer.h:36: 
>>
>> error: with 'java::lang::StringBuffer*
>> java::lang::StringBuffer::StringBuffer$append(java::lang::CharSequence*,
>> jint, jint)'
>> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/java/lang/StringBuffer.h:102: 
>>
>> error: 'java::lang::AbstractStringBuffer*
>> java::lang::StringBuffer::StringBuffer$append(java::lang::CharSequence*)'
>> cannot be overloaded
>> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/java/lang/StringBuffer.h:35: 
>>
>> error: with 'java::lang::StringBuffer*
>> java::lang::StringBuffer::StringBuffer$append(java::lang::CharSequence*)'
>> make[3]: *** [interpret.lo] Error 1
>>
>> Is there an issue with gcj and the use of covariant return types from 
>> 1.5?
>>
>> The methods in question are StringBuffer.append(char),
>> StringBuffer.append(CharSequence,int,int) and
>> StringBuffer.append(CharSequence). All return a StirngBuffer and
>> override methods with the same signature but a return type of
>> AbstractStringBuffer in AbstractStringBuffer.
> 
>  From #gcj:
> 
> (09:49:57 AM) daney: You could keep the common code factored out, but 
> just use different names for the methods.  Because the java code has to 
> return the correct type and synchronize, there have to be little stub 
> methods in the child class that return super.method().  Since we already 
> have to have these little stubs, they might as well return 
> super.otherMethod()
> 
> (09:50:40 AM) tromey: yeah
> 
> (09:50:44 AM) daney: That way the public methods would not have to 
> override anything.

More Ideas...


(09:57:21 AM) tromey: ISTR some special code in the new gcjh for this stuff
(09:57:22 AM) tromey: hmm
(10:02:45 AM) daney: Any overridden method is declared to return the same type as the base class method?
(10:03:19 AM) daney: Something like that might work.
(10:04:14 AM) daney: I don't know if you would have to do anything for interfaces.
(10:04:50 AM) tromey: I'd have to look it up
(10:05:01 AM) tromey: whatever I did here required a lot of thought
(10:05:13 AM) tromey: to ensure myself that it was correct
(10:06:19 AM) daney: When building with -enable-java-maintainer-mode we use the system gjavah and not the one from the code being built, don't we?
(10:06:51 AM) tromey: yeah
(10:06:57 AM) tromey: I think so
(10:06:58 AM) daney: I wonder if that is his problem.