Community
Participate
Working Groups
Build: I20061121-1845 VM: IBM 1.5 SR3 1) Opened a class file editor in java.util.Arrays 2) Selected a private static method in the outline view: private static <T> T[] cloneSubarray(T[] a, int from, int to) 3) Hit Ctrl+Shift+G to start global search for references. An internal error dialog opens (NPE shown below). This is consistently reproducible for me. java.lang.NullPointerException at org.eclipse.jdt.internal.core.search.matching.MethodLocator.matchReportReference(MethodLocator.java:339) at org.eclipse.jdt.internal.core.search.matching.PatternLocator.matchReportReference(PatternLocator.java:407) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.reportMatching(MatchLocator.java:2058) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.reportMatching(MatchLocator.java:2464) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.reportMatching(MatchLocator.java:2211) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.process(MatchLocator.java:1558) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1042) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1083) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1204) at org.eclipse.jdt.internal.core.search.JavaSearchParticipant.locateMatches(JavaSearchParticipant.java:94) at org.eclipse.jdt.internal.core.search.BasicSearchEngine.findMatches(BasicSearchEngine.java:219) at org.eclipse.jdt.internal.core.search.BasicSearchEngine.search(BasicSearchEngine.java:504) at org.eclipse.jdt.core.search.SearchEngine.search(SearchEngine.java:549) at org.eclipse.jdt.internal.ui.search.JavaSearchQuery.run(JavaSearchQuery.java:143) at org.eclipse.search2.internal.ui.InternalSearchUI$InternalSearchJob.run(InternalSearchUI.java:94) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)
Created attachment 54766 [details] Proposed patch This patch fixes the NPE which happen when method binding is not valid, but also test case where JRE 1.5.0 is attached to a project with 1.4 compliance (I guess this is your test case John, isn't it?). It passes all JDT tests (CORE+UI) and also does not impact search performance tests on method references (resolved). It was necessary to verify this performance result as the fix is to look at class file version on each document where potential matches are found and use the compliance corresponding the highest version number found there to compile attached source...
Philippe, do you think it would be an acceptable behavior?
The project sources should still be compiled at the explicit project compliance level. If not, you would surface erasure matches which are going to be very misleading. Also, semantics are changing across compliance levels, and could mean headaches in search results.
Comment on attachment 54766 [details] Proposed patch Other options to solve this is either to split documents bundle in several ones (one per source level), or, a better solution, directly extract method references from the class file itself instead of parsing the source again (bug 127442 is already opened for this second option).
Yes, my case is projects targetting 1.4 runtime, but compiling against a 1.5 JRE.
*** Bug 196923 has been marked as a duplicate of this bug. ***
(In reply to comment #6) > *** Bug 196923 has been marked as a duplicate of this bug. *** > ------- Comment #3 from frederic_fusier@fr.ibm.com 2007-07-18 08:29 ------- Can you confirm that you're in the same context than bug 166093 (ie. targetting 1.4 runtime but compiling against JRE 1.5 or 1.6)? No, it is not the case: I am compiling agains 1.6, and targetting 1.6
(In reply to comment #7) > No, it is not the case: I am compiling agains 1.6, and targetting 1.6 > Reopen bug 196923 as it sounds not to be a duplicate...
*** Bug 196974 has been marked as a duplicate of this bug. ***
Created attachment 74074 [details] New proposed patch As the number of duplicate increase a lot, I think I will apply a minimal patch to avoid this NPE to occur. The behavior is not really perfect as the found matches are potential but corresponds to the reality of the user context: 1.5 code is not valid with 1.4 compliance... Unfortunately, I wasn't able to find a test case with our Java Search tests context to reproduce this problem, so verifier will need to follow steps in comment 0 to verify that this bug is well fixed...
Last patch released for 3.4M1 in HEAD stream.
Verified for 3.4M1 using build I20070802-0800.
Frederic, please backport to 3.3.1
Patch released for 3.3.1 in R3_3_maintenance stream.
.
*** Bug 201109 has been marked as a duplicate of this bug. ***
Verified for 3.3.1 using build M20070831-2000.
