GCJ and generics

[Cedric Berger]

Ranjit Mathew wrote:

>Cedric Berger wrote:
>  
>
>>> Unfortunately, the compiler gets partway through (with lots of
>>>warnings) and then gives the following errors like:
>>>
>>>c:\DOCUME~1\eliasen\LOCALS~1\Temp/ccusaaaa.s: Assembler messages:
>>>c:\DOCUME~1\eliasen\LOCALS~1\Temp/ccusaaaa.s:4439: Error: symbol
>>>`__ZN5frink5units22BasicObjectEnumeration11nextElementEv' is already defined
>>>
>>>
>>>      
>>>
>>I think generics define multiple functions with the same arguments
>>but different return values. Could that be the problem?
>>    
>>
>
>That could most likely be the case, especially
>considering the error messages.
>
>Is this the way generics would be handled in JDK 1.5?
>I mean, GJ was a proposal - has it been accepted
>as the way of doing things?
>  
>
It's in public review, but I don't think that part of the specs is 
controversial.
 From JSR 14, talking about "bridge methods":
  Example 17 Bridge methods with the same parameters as normal methods.

  class C<A> { abstract A next(); }
  class D extends C<String> { String next() { return ""; } }

  This will be translated to:
    class C { abstract Object next(); }
    class D extends C<String> {
    String next/*1*/() { return ""; }
    Object next/*2*/() { return next/*1*/(); }
  }

  A compiler would reject that program because of the double declaration 
of next. But the bytecode
  representation of the program is legal, since the bytecode always 
refers to a method via its the full
  signature and therefore can distinguish between the two occurrences of 
next. Since we cannot make the
  same distinction in the Java source, we resorted to indices in /* ... 
*/ comments to make clear which
  method a name refers to.

  The same technique is used to implement method overriding with 
covariant return types1.
Cedric