Community
Participate
Working Groups
"Call Hierarchy" show no result for "read()" if rename "read" to "readxxxx", result show up. [code]: public class CA { public void read(){ System.out.println("read"); } } public class CB { public void callRead(){ CA ca = new CA(); ca.read(); } }
I cannot reproduce using 3.1 M4. So, some questions to try to understand: 1) Which build are you using? 2) When you search references to this method instead of opening Call Hierarchy view, do you find any match? 3) Does this problem happen if you try it in a brand new workspace?
> 1) Which build are you using? eclipse-SDK-3.1M3-win32 > 2) When you search references to this method instead of opening Call > Hierarchy view, do you find any match? yes, i found matches in class CB(see my sample code) > 3) Does this problem happen if you try it in a brand new workspace? yes, the problem happended in new instance(which i unzip from eclipse-SDK- 3.1M3-win32.zip) and new workspace. i tried in a 3.0 build, it cannot be reproduced. maybe it only exists in 3.1 M3.
Thanks for the answers. This a duplicate of bug 73784 => this issue has been fixed for 3.1 M4. *** This bug has been marked as a duplicate of 73784 ***
hi, this time method named "start" has the problem! Reproducable in 3.1 M4. [code] public class CA { private void run() { CB b = new CB(); b.start(); } } public class CB { public void start() { } } [/code] search references to this method has matches but opening Call Hierarchy has no matches.
and maybe the log will be helpful: !SESSION 2005-01-19 14:42:03.582 ----------------------------------------------- eclipse.buildId=I20041216-2000 java.version=1.5.0-rc java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=zh_CN Command-line arguments: -os win32 -ws win32 -arch x86 !ENTRY org.eclipse.jdt.ui 4 10001 2005-01-19 14:50:58.850 !MESSAGE Internal Error !STACK 0 java.lang.NullPointerException at org.eclipse.jdt.internal.compiler.lookup.TypeVariableBinding.boundCheck(TypeVariableBinding.java:72) at org.eclipse.jdt.internal.compiler.lookup.ParameterizedTypeBinding.resolve(ParameterizedTypeBinding.java:574) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:53) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.superclass(BinaryTypeBinding.java:775) at org.eclipse.jdt.internal.compiler.lookup.ClassScope.detectHierarchyCycle(ClassScope.java:973) at org.eclipse.jdt.internal.compiler.lookup.ClassScope.detectHierarchyCycle(ClassScope.java:935) at org.eclipse.jdt.internal.compiler.ast.SingleTypeReference.getTypeBinding(SingleTypeReference.java:42) at org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveType(TypeReference.java:141) at org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveSuperType(TypeReference.java:104) at org.eclipse.jdt.internal.compiler.lookup.ClassScope.findSupertype(ClassScope.java:1067) at org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectSuperclass(ClassScope.java:725) at org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectTypeHierarchy(ClassScope.java:862) at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.connectTypeHierarchy(CompilationUnitScope.java:243) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings(LookupEnvironment.java:195) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:826) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:890) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1007) at org.eclipse.jdt.internal.core.search.JavaSearchParticipant.locateMatches(JavaSearchParticipant.java:94) at org.eclipse.jdt.internal.core.search.SearchBasicEngine.findMatches(SearchBasicEngine.java:196) at org.eclipse.jdt.internal.core.search.SearchBasicEngine.search(SearchBasicEngine.java:382) at org.eclipse.jdt.core.search.SearchEngine.search(SearchEngine.java:512) at org.eclipse.jdt.internal.corext.callhierarchy.CallerMethodWrapper.findChildren(CallerMethodWrapper.java:71) at org.eclipse.jdt.internal.corext.callhierarchy.MethodWrapper.performSearch(MethodWrapper.java:253) at org.eclipse.jdt.internal.corext.callhierarchy.MethodWrapper.doFindChildren(MethodWrapper.java:194) at org.eclipse.jdt.internal.corext.callhierarchy.MethodWrapper.getCalls(MethodWrapper.java:76) at org.eclipse.jdt.internal.ui.callhierarchy.DeferredMethodWrapper.getCalls(DeferredMethodWrapper.java:62) at org.eclipse.jdt.internal.ui.callhierarchy.DeferredMethodWrapper.fetchDeferredChildren(DeferredMethodWrapper.java:80) at org.eclipse.ui.progress.DeferredTreeContentManager$1.run(DeferredTreeContentManager.java:168) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:66)
This new problem already has been referenced in bug 83083. *** This bug has been marked as a duplicate of 83083 ***
However, I was not able to reproduce the NPE using 3.1 M4 and Call Hierarchy view correctly shows one match... Did I miss something?
Frédéric: i'm curious and wondered of the bug. if not bother you, would you explain why it is sensitive to specific word like "start", and will not happend to words even has the same length? thanks a lot.
I'm not absolutely sure as I cannot reproduce your comment 4 issue following your steps... However, the "theoritical" explanation is that search engine works in two passes. First pass: it looks in search scope index files whether there are potential matches or not. Second pass: it compiles these file to resolve and locate matches in these files. Search engine finds "start" method in 1.5.0 library, so it compiles and resolves these files... and broke on this NPE! When you change the name and search for "startxxx", there's no potential matches in 1.5.0 library, so no need to compile and avoid the issue :-) Hope this answer your question.
