Community
Participate
Working Groups
Build ID: M20080221-1800 (can't yet select version 3.3.2 in bugzilla?) I'm afraid I found a bug in the fix for bug 160301: Steps To Reproduce: Simply add "abstract" to class Test$A in JavaSearchBugsTests#testBug160301() and watch the old behavior, i.e., an overridden method is wrongly reported as a match. I seems that the following branch in MethodLocator#resolveLevelAsSubtype() is not complete: if (level != IMPOSSIBLE_MATCH) { if (!type.isAbstract() && !type.isInterface()) { // if concrete class, then method is overridden level |= OVERRIDDEN_METHOD_FLAVOR; } return level; } If "type" is abstract this doesn't necessarily say that the method is abstract, too. I assume that for abstract classes the original method has to be looked up to check whether the method is indeed abstract. If the MethodPattern has its field "focus" set, this could be used for easily checking the method. If focus is not set, this might require more efforts. Just to make sure I correctly understand the exact meaning of "overridden" in this context: when searching for references to an abstract method, this translates to "find all references to any implementations of this method" whereas searching for references to a concrete method means "find all references to this exact method, but no references definitely referring to an overriding method" right?
I think this bug is still alived in Version: 3.4.0 Build id: I20080617-2000 Is there any plan to fix this bug?
(In reply to comment #0) > Build ID: M20080221-1800 > (can't yet select version 3.3.2 in bugzilla?) > > I'm afraid I found a bug in the fix for bug 160301: > ... > > Just to make sure I correctly understand the exact meaning of "overridden" > in this context: > when searching for references to an abstract method, this translates to > "find all references to any implementations of this method" > whereas searching for references to a concrete method means > "find all references to this exact method, > but no references definitely referring to an overriding method" > right? > It may be a good explanation :-) I just want to add, to be sure that it's perfectly clear, that even while searching for references to an abstract method, matches on overriding methods of any implementations will not be returned... E.g. interface I { void foo(); } class A implements I { public void foo() {} } class B extends A { public void foo() {} void bar () { foo(); } } Searching for reference to I.foo() will not return the match in B.bar() as foo() is overridden in B...
Created attachment 139636 [details] Proposed patch Look for for the corresponding method of matching type to see if it's abstract or not. If no method was found, use the type instead (as it was done before).
Released for 3.6M1 in HEAD stream.
Verified for 3.6M1 using build I20090802-2000
