Community
Participate
Working Groups
public interface IGen<T> { T foo(T t); } When I try to add a method breakpoint on foo, I get an error logged : 'Source method signature could not be resolved'
The error is misleading - but we don't support breakpoints on interfaces.
I get the same problem in a class. public class TestGen<T> { T foo() { return null; } }
*** This bug has been marked as a duplicate of 94903 ***
This bug seems not to be a dup of bug 94903, since I can still reproduce in I20050816-1235. The problem is the type variable T in the signature of T foo().
When trying to create a method entry breakpoint on a method that returns a type variable it appears that the resolved method signature return from jdt core is incorrect. For the method "X foo(int index)" method.getSignature return "(I)QX;". We expected it to return (I)TX;" Moving to jcore for comment. My sample code is this: public class FooList<X> extends ArrayList<X> { X foo(int index) { return super.get(index); } public static void main(String[] args) { FooList<String> fooList = new FooList<String>(); fooList.add("one"); fooList.foo(0); } }
IMethod#getSignature() is not supposed to return resolved info. Only the DOM AST could help you in this case. Do you need the parameter X in this case, or do you need Object (its erasure) found in the .class file (and maybe returned by JDI) ?
Jerome, comment#5 was not completely accurate, we are using: IType.resolve(String name) The IType is the "SourceType" FooList and the name we are passing in is "X". In this case it should return a resolved type? (it returns null).
Unfortunately, IType#resolveType(...) takes a type name, not a type parameter name.
Note: the VM/JDI returns the following as the method's siganture: (I)Ljava/lang/Object; So, we will not match on TX either.
Fixed in ToggleBreakpointAdapter. When type cannot be resolved we then check against the type's type parameters for a match and resolve to Object when the name matches.
Please verify, Kevin.
I don't know your code and I have not looked at the fix, but it sounds like you would assume that the erasure of a type variable is always Object. This is e.g. not the case here: public class FooList<X extends Number> extends ArrayList<X> { X foo(int index) { return super.get(index); } }
verified
I filed bug 132543 for comment 12.