#135 More Unit breaks JDT Call Hierarchy

[Mattias Andersson]

Call Hierarchy sporadically fails to find callers and return empty result. It turns out that More Unit repeatedly changes the search scope for Call Hierarchy. The class CallHierarchy is a singleton and is shared between JDT Call Hierarchy and More Unit.

The org.moreunit.util.MethodCallFinder class is not changed for some time, but this has probably always been a problem. However I think that the problem might be related to bug #134, i.e. the search scope is now more frequently changed.

CallHierarchy.setSearchScope(IJavaSearchScope) line: 177    
MethodTestCallerFinder(MethodCallFinder).getMatches(IProgressMonitor) line: 51  
ClassTypeFacade.getCorrespondingTestMethods(IMethod, MethodSearchMode) line: 143    
MoreUnitAnnotationModel.annotateTestedMethods(IType, ClassTypeFacade,         AnnotationModelEvent) line: 223   
MoreUnitAnnotationModel.access$2(MoreUnitAnnotationModel, IType, ClassTypeFacade,     AnnotationModelEvent) line: 217   
MoreUnitAnnotationModel$1.run(IProgressMonitor) line: 200   
Worker.run() line: 54

We had to back down to version 3.0.4, and now Call Hierarchy seems to work properly.

[Nicolas Demengel]

Wow, thanks a lot for this one! Looking at the code of CallHierarchy (http://grepcode.com/file/repository.grepcode.com/java/eclipse.org/4.3/org.eclipse.jdt/ui/3.9.0/org/eclipse/jdt/internal/corext/callhierarchy/CallHierarchy.java), it seems like we can instantiate CallHierarchy and avoid the problem.

I will look at it soon.

[Nicolas Demengel]

Last week I've had a look at the problem, and unfortunately CallHierarchy is designed in such a way that it has to be a singleton, even though one can instantiate it several times... For instance, CallerMethodWrapper#getSearchScope() references the singleton.

Basically that means that we are stuck, unless we find a way to prevent concurrent executions of the search. Another possibility would be to copy/paste/modify the code of CallHierarchy (yurk!) or attempt to extend/override some of its parts (I've tried and it is equivalent to the copy/paste/modify solution).

Note that the difference of behavior observed in version 3.0.5 is due to the fact that CallHierarchy is now used by default to search for test methods (and thus to annotate tested methods), whereas previously the user had to explicitly ask for it. So the problem could occur, but only when "jumping", which was less likely to happen during a call hierarchy computation.

Considering the many problems we have with the method annotation feature (OutOfMemoryErrors, even if apparently not directly due to our code), I would propose to deactivate that feature by default.

@gianasita: any other idea?

[Nicolas Demengel]

The feature is now deactivated by default, plus it takes care to set the original search scope back after the search.