| Summary: | [DOM] IMethodBinding.overrides(IMethodBinding) is wrong when super method is in a generic class | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Carsten Pfeiffer <carsten.pfeiffer> |
| Component: | Core | Assignee: | JDT-Core-Inbox <jdt-core-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | Olivier_Thomann, philippe_mulet |
| Version: | 3.2.2 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Linux | ||
| Whiteboard: | stalebug | ||
Are you creating the two method bindings in the same ast creation process ? (In reply to comment #1) Yes. I'm navigating my way from the sub-method to the super-method via methodBinding.getDeclaringClass().getSuperClass().getDeclaredMethods(). Reproduced. I am investigating. Added two disabled regression tests: org.eclipse.jdt.core.tests.dom.ASTConverter15Test._test0270() org.eclipse.jdt.core.tests.dom.ASTConverter15Test._test0271() Philippe, the first case works fine when the method binding are retrieved from the declaration of each method. But when I get the method binding from the superlass using methodBinding.getDeclaringClass().getSuperClass().getDeclaredMethods() I end up with a different binding (on the compiler side) and the call overrides(..) returns false. Does it make sense to get two different compiler method bindings in this case ? When retrieving the method binding using resolveBinding() on the method declaration I get a compiler method binding that has a SourceTypeBinding as the declaring class. When I use the chained calls, I get a ParameterizedMethodBinding that has a ParameterizedTypeBinding has the declaring class. Any idea where this is coming from ? This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |
Build ID: M20070212-1330 Steps To Reproduce: Consider these two classes, a templatized super class GenericBase and a subclass Bug: package foo; public class GenericBase<T> { public void someMethod() {} } package foo; public class Bug extends GenericBase<String> { @Override public void someMethod() {} } Now build a DOM out of this and get hold of the method bindings for those two methods. When asking the sub-method's binding whether it overrides the super-method, then false will be returned. I.e. IMethodBinding.overrides(IMethodBinding) will wrongly return false if the latter binding stems from a generic super class. More information: Note that Bindings.isSubsignature(IMethodBinding, IMethodBinding) works correctly (but is not API).