Community
Participate
Working Groups
Can't reproduce the problem with a test :(. Next is what considered as important details: There are three compilation units (with single public class) in the same package, cu1 and cu2 main types are referenced from cu3. cu3 imports both cu1 and cu2 regardless of the fact they reside in same package. Perform deletion of these classes as an atomic workspace command (IWorkspaceRunnable, IMO this prevents index from updating, which may be a part of the problem). Upon deletion of each class some code which uses SearchEngine is invoked to collect references to the class being deleted. Deletion of cu1 goes without any problem, but on deletion of cu2 a ProblemReferenceBinding (with problemId == NotFound(1)) is created for the import of cu1 inside cu3. And TypeDeclarationPattern.matchLevelForType fails with NPE with because ProblemReferenceBinding.getPackage() is null. Changing order of deletion helps. Stacktrace follows. The call of SearchEngine looks like: IType type = cu.getTypes()[0]; IJavaSearchScope searchScope = SearchEngine.createJavaSearchScope(new IJavaElement[] { type.getJavaProject() }); ISearchPattern searchPattern = SearchEngine.createSearchPattern(type, IJavaSearchConstants.ALL_OCCURRENCES); new SearchEngine().search(..., searchPattern, searchScope, ...) java.lang.NullPointerException at org.eclipse.jdt.internal.core.search.matching.TypeDeclarationPattern.matchLevelF orType(TypeDeclarationPattern.java:326) at org.eclipse.jdt.internal.core.search.matching.TypeDeclarationPattern.matchLevel (TypeDeclarationPattern.java:310) at org.eclipse.jdt.internal.core.search.matching.OrPattern.matchLevel (OrPattern.java:152) at org.eclipse.jdt.internal.core.search.matching.MatchSet.reportMatching (MatchSet.java:224) at org.eclipse.jdt.internal.core.search.matching.MatchingOpenable.locateMatchesInCo mpilationUnit(MatchingOpenable.java:331) at org.eclipse.jdt.internal.core.search.matching.MatchingOpenable.locateMatches (MatchingOpenable.java:174) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches (MatchLocator.java:1323) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches (MatchLocator.java:586) at org.eclipse.jdt.core.search.SearchEngine.search(SearchEngine.java:412)
Created attachment 4774 [details] JUnit test case Initial description is a bit wrong - only first deleted cu (cu1) should be explicitly imported into cu3. And names of the CUs should be simmilar (only suffixes differ). cu1 and cu2 are referenced by their fq names. Before running this testcase, you need a java project (project as a source root)named "SearchEngineBindingProblemTest" in your workspace. If I create it from setUp, it has some problems with classpath, so MatchingOpenable.shouldResolve became false (MatchLocator gets AbortCompilation), so no attempt to resolve reference done.
A lot of changes occured in this area in 2.1. Could you please try with Eclipse 2.1 and see if you still have the problem?
Yes, it is reproducable in 2.1. Hope, next comment won't be "please suggest a fix". I consider testcase is pretty good contribution from my side.
Thanks a lot for your test case. Fixed TypeDeclarationPattern.matchLevelForType(...) to handle ProblemReferenceBindings. Added regression test JavaSearchTests.testTypeOccurence2()
Verified.
