Bug 113950 - [1.5][compiler] Problems implementing inherited generic abstract methods and type erasure
Summary: [1.5][compiler] Problems implementing inherited generic abstract methods and ...
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.1.1   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: 3.1.2   Edit
Assignee: Philipe Mulet CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-10-27 08:22 EDT by Henning Niss CLA
Modified: 2006-01-09 11:06 EST (History)
0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Henning Niss CLA 2005-10-27 08:22:54 EDT 
The code below produces an error with the compiler in Eclipse 3.1.1 (the exact
message is pasted in below): "The type Test.C<T> must implement the inherited
abstract method Test.I<List<T>>.foo(List<S>)". The code compiles fine with 
Sun's javac version 1.5.0_04.

This seems related to bugs 100869 and 105645 (but none of those involve an
interface and the error message seems to be different).

package gentest;

import java.util.List;

public class Test {
	public interface I<T> {
	        public <S extends T> void foo(List<S> ls);
	}

	public abstract class A<T> implements I<T> {
	        public <S extends T> void foo(List<S> ls) { }
	}

	public class C<T> extends A<List<T>> { }
}


Severity: 	2
Description:	Name clash: The method foo(List<S>) of type Test.A<List<T>> has the
same 	
		erasure as foo(List<S>) of type Test.I<List<T>> but does not override it
Resource:	Test.java
In Folder:	gen/src/java/gentest
Location:	line 14

Severity:	2
Description:	The type Test.C<T> must implement the inherited abstract method 
		Test.I<List<T>>.foo(List<S>)
Resource:	Test.java
In Folder:	gen/src/java/gentest
Location:	line 14
Comment 1 Olivier Thomann CLA 2005-10-27 09:09:30 EDT 
Could reproduce in HEAD.
Comment 2 Kent Johnson CLA 2005-10-31 14:15:28 EST 
Proposed fix is to the constructor:

ParameterizedMethodBinding(ParameterizedTypeBinding, MethodBinding)

replace initialize variable bounds for loop with:

for (int i = 0; i < length; i++) {
  TypeVariableBinding originalVar = originalVars[i];
  TypeVariableBinding substitutedVar = substitutedVars[i];
  TypeBinding substitutedSuperclass = Scope.substitute(substitution, 
originalVar.superclass);
  substitutedVar.superclass =
    (ReferenceBinding) (substitutedSuperclass.isArrayType() 
      ? parameterizedDeclaringClass.environment.getType(JAVA_LANG_OBJECT)
      : substitutedSuperclass);
  substitutedVar.superInterfaces = Scope.substitute(substitution, 
originalVar.superInterfaces);
  if (substitutedVar.superclass.isInterface()) {
    if (substitutedVar.superInterfaces == NoSuperInterfaces) {
      substitutedVar.superInterfaces = new ReferenceBinding[] 
{substitutedVar.superclass};
    } else {
      int size = substitutedVar.superInterfaces.length;
      System.arraycopy(substitutedVar.superInterfaces, 0, 
substitutedVar.superInterfaces = new ReferenceBinding[size + 1], 1, size);
      substitutedVar.superInterfaces[0] = substitutedVar.superclass;
    }
    substitutedVar.superclass = parameterizedDeclaringClass.environment.getType
(JAVA_LANG_OBJECT);
  }
  if (originalVar.firstBound != null) {
    substitutedVar.firstBound = originalVar.firstBound == 
originalVar.superclass
      ? substitutedSuperclass // could be array type
      : substitutedVar.superInterfaces[0];
  }
}
Comment 3 Philipe Mulet CLA 2005-11-07 04:31:31 EST 
Released similar fix. Added GenericTypeTest#test870.
Fixed in 3.2 and 3.1.2 streams.
Comment 4 Olivier Thomann CLA 2005-12-13 10:15:44 EST 
Verified for 3.2M4 in I20051212-2000
Comment 5 Olivier Thomann CLA 2006-01-09 11:06:46 EST 
Verified for 3.1.2 in M20060109-0800.