Eclipse IDE - Open Call Hierarchy is empty/broken

烈酒焚心 提交于 2019-11-29 05:26:01
Skip

The following may help:

  • Calling eclipse with eclipse.exe -clean -refresh forces Eclipse to rebuild the index. After that the feature worked again.
  • Closing and re-opening the project.
Christian Lischnig

I also tried the suggestions above, as well as the hint given here: http://mschrag.blogspot.co.at/2009/01/open-type-cant-find-your-class.html

Nothing worked until today when I found out that I am a donkey... I once configured a filter in the "Call Hierarchy" view and so no entries were shown because filtered out. Once I removed / disabled the filter everything worked fine again.

When you go to the eclipse bug report for this issue, somebody says, you should install over the Market place the Java 12 support.
When I installed it, it was working properly again

Also, you can try to delete the workspace and get it recreated. Make sure all your projects are backed up.

For Kepler and PDT (PHP IDE) it is broken in at least PDT 3.2.0 and 3.3.0 (tried them both). The fix is in 3.3.1 and updating to that was all I had to do get the call hierarchy working again.

(apologies, I'm not yet allowed to add comments, however this should prove handy to many)

In my case it seemed my workspace was contaminated.

Opening/closing projects and starting with clean did not fix. I had to start off a new workspace.

Fedora 20, Eclipse Kepler.

I have the same behavior with eclipse Kepler (4.3.2).

I found out, that there is a bug with methods with signature of:

void get(Object o)
Object get(Object o)

In the eclipse Error Log view I find the following exception:

java.lang.NullPointerException
    at org.eclipse.jdt.internal.core.search.matching.ClasspathSourceDirectory.directoryTable(ClasspathSourceDirectory.java:52)
    at org.eclipse.jdt.internal.core.search.matching.ClasspathSourceDirectory.findClass(ClasspathSourceDirectory.java:109)
    at org.eclipse.jdt.internal.core.search.matching.JavaSearchNameEnvironment.findClass(JavaSearchNameEnvironment.java:146)
    at org.eclipse.jdt.internal.core.search.matching.JavaSearchNameEnvironment.findType(JavaSearchNameEnvironment.java:185)
    at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:145)
    at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:197)
    at org.eclipse.jdt.internal.compiler.lookup.Scope.getTypeOrPackage(Scope.java:2799)
    at org.eclipse.jdt.internal.compiler.lookup.Scope.getType(Scope.java:2556)
    at org.eclipse.jdt.internal.core.search.matching.MatchLocator.getType(MatchLocator.java:899)
    at org.eclipse.jdt.internal.core.search.matching.MatchLocator.getMethodBinding0(MatchLocator.java:955)
    at org.eclipse.jdt.internal.core.search.matching.MatchLocator.getMethodBinding(MatchLocator.java:907)
    at org.eclipse.jdt.internal.core.search.matching.MethodLocator.matchMethod(MethodLocator.java:327)
    at org.eclipse.jdt.internal.core.search.matching.MethodLocator.resolveLevel(MethodLocator.java:664)
    at org.eclipse.jdt.internal.core.search.matching.ClassFileMatchLocator.locateMatches(ClassFileMatchLocator.java:209)
    at org.eclipse.jdt.internal.core.search.matching.MatchLocator.process(MatchLocator.java:1699)
    at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1143)
    at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1184)
    at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1301)
    at org.eclipse.jdt.internal.core.search.JavaSearchParticipant.locateMatches(JavaSearchParticipant.java:95)
    at org.eclipse.jdt.internal.core.search.BasicSearchEngine.findMatches(BasicSearchEngine.java:231)
    at org.eclipse.jdt.internal.core.search.BasicSearchEngine.search(BasicSearchEngine.java:515)
    at org.eclipse.jdt.core.search.SearchEngine.search(SearchEngine.java:584)
    at org.eclipse.jdt.internal.corext.callhierarchy.CallerMethodWrapper.findChildren(CallerMethodWrapper.java:155)
    at org.eclipse.jdt.internal.corext.callhierarchy.MethodWrapper.performSearch(MethodWrapper.java:301)
    at org.eclipse.jdt.internal.corext.callhierarchy.MethodWrapper.doFindChildren(MethodWrapper.java:232)
    at org.eclipse.jdt.internal.corext.callhierarchy.MethodWrapper.getCalls(MethodWrapper.java:84)
    at org.eclipse.jdt.internal.ui.callhierarchy.DeferredMethodWrapper.getCalls(DeferredMethodWrapper.java:65)
    at org.eclipse.jdt.internal.ui.callhierarchy.DeferredMethodWrapper.fetchDeferredChildren(DeferredMethodWrapper.java:79)
    at org.eclipse.ui.progress.DeferredTreeContentManager$1.run(DeferredTreeContentManager.java:235)
    at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)

In the end, it looks like a bug in this version:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=401272

I assume, that upgrading at least to version 4.4 (Luna) will solve this problem.

In my case I was trying to get the call hierarchy of a method in the derived class of an abstract class. The requested method was declared abstract in the base class. When I opened the call hierarchy directly on the abstract method instead of the implemented one, everything worked well. (Eclipse Neon).

My problem was that Open Call Hierarchy was searching only the project not the entire Workspace. So I had to click on the small down arrow (in the Call Hierarchy view window on the right; it is the "View Menu" arrow -- a triangle pointing down) in Call Hierarchy view, set the Search Scope > Workspace.

If the call Hierarchy is not opening, it might be because of the project is not imported as a java project, rather it would be displayed in the file stucture. You may want to enable the project facet through:

right click on the project -> project facet.  

If you dont see anything listed, you need

configure the project facet -> Apply -> ok. 
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!