Community
Participate
Working Groups
I did a java search (ctrl-h) for references to "String". The search failed with this exception in the log: at org.eclipse.jdt.internal.ui.search.JavaSearchResultCollector.accept(JavaSearchResultCollector.java:121) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.report(MatchLocator.java:921) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.report(MatchLocator.java:914) at org.eclipse.jdt.internal.core.search.matching.PatternLocator.matchReportReference(PatternLocator.java:195) at org.eclipse.jdt.internal.core.search.matching.TypeReferenceLocator.matchReportReference(TypeReferenceLocator.java:178) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.reportMatching(MatchLocator.java:1122) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.reportMatching(MatchLocator.java:1297) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.reportMatching(MatchLocator.java:1308) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.reportMatching(MatchLocator.java:1183) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.process(MatchLocator.java:855) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:588) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:625) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:712) at org.eclipse.jdt.core.search.SearchEngine.search(SearchEngine.java:568) at org.eclipse.jdt.internal.ui.search.JavaSearchOperation.execute(JavaSearchOperation.java:98) at org.eclipse.ui.actions.WorkspaceModifyOperation$1.run(WorkspaceModifyOperation.java:71) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1555) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1572) at org.eclipse.ui.actions.WorkspaceModifyOperation.run(WorkspaceModifyOperation.java:85) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:101) There are two things wrong here: 1) We should make sure that we handle null "enclosingElements" in our search result acceptor (at least not NPE). The API clearly says we have to handle the case. 2) I haven't seen this behaviour from the java model before. What's the change, and why. Note that the reference that's being reported is in the package declaration of a binary type (in an external jar).
The easiest for now is to ignore those results since the whole Java search is based on the enclosing element (handle identifier, groupd by key,...).
>We should make sure that we handle null "enclosingElements" in our search >result acceptor (at least not NPE). The API clearly says we have to handle the >case. Yes. For now we ignore such results. >Which build did you use? Which jdt core? I20030930 + plugin-export 20031006.
Note that the reported resource is the project the jar is in. This, however is useless to us, since we cannot determine the class file just from the project and a start and end position.
Released guard against null-enclosing element for I20031008. Also guarded NLSSearchResultCollector.
Thomas, please provide a patch for M4. Kent, this one might be related to bug 44286. We didn't saw this in the past either.
Dani released a patch already (RTFBR, Dirk;-)
OK, moving to Kent then. Kent please dispose if the PR isn't of any value ;-).
Now prevent obsolete methods from being passed to the collector
*** Bug 44286 has been marked as a duplicate of this bug. ***
Verified.
