Community
Participate
Working Groups
I move a class from one plug-in to another and then undid the move. Now whenever I try to do any searching/refactoring using the class, I get the following NPE. I am using eclipse.buildId=I20081016-1126 java.fullversion=J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32 j9vmwi3223-20071007 (JIT enabled) J9VM - 20071004_14218_lHdSMR JIT - 20070820_1846ifx1_r8 GC - 200708_10 BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US Command-line arguments: -os win32 -ws win32 -arch x86 -debug -consolelog -console java.lang.NullPointerException at org.eclipse.jdt.internal.core.search.matching.MatchLocator.reportMatching(MatchLocator.java:2149) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.reportMatching(MatchLocator.java:2595) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.reportMatching(MatchLocator.java:2324) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.process(MatchLocator.java:1616) 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:1215) at org.eclipse.jdt.internal.core.search.JavaSearchParticipant.locateMatches(JavaSearchParticipant.java:94) at org.eclipse.jdt.internal.core.search.BasicSearchEngine.findMatches(BasicSearchEngine.java:223) at org.eclipse.jdt.internal.core.search.BasicSearchEngine.search(BasicSearchEngine.java:506) at org.eclipse.jdt.core.search.SearchEngine.search(SearchEngine.java:551) at org.eclipse.jdt.internal.ui.search.JavaSearchQuery.run(JavaSearchQuery.java:144) at org.eclipse.search2.internal.ui.InternalSearchUI$InternalSearchJob.run(InternalSearchUI.java:93) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
I cannot reproduce it with a simple test case using I20081026-2000. As I didn't change anything in search since 3.5M2, I doubt that the explanation could be that builds are different... Looking at corresponding line of code does not help a lot either. So, we need to figure out what is special in your config/wksp: 1) Can you reproduce in a fresh wksp? 2) Can you reproduce in the same wkps but another (simple) class? 3) Do you still have the problem after an exit/restart? 4) Anything else in the .log? If you can reproduce it each time you follow this scenario, then it would be interesting to set JDT/Core search debug ON by adding following lines in .options file: # Turn on debug tracing for org.eclipse.jdt.core plugin org.eclipse.jdt.core/debug=true # Reports java search activity org.eclipse.jdt.core/debug/search=true TIA
It turns out this problem was caused by a failure in the Source>Externalize Strings... wizard. I was Internalizing strings in order to move classes to another plug-in. The string in the message bundle was ChangeFilePropertiesPreferencePage_TextTypesText=Text types are files that have one of the following properties:\n\ta) Are associated under the Eclipse Text Content Type tree\n\tb) Have a MIME prefixed by the "text/" category When it was internalized, the " near the end were not escaped which caused a compile error. I didn't see the compile error because I have error on non-NLSed set to true and was going to externalize after the move. So, there are two failures here: 1) Internalizing a string should escape double quotes 2) A compile error shouldn't cause an NPE in search
Search is intended to be resilient to errors, this is just a bug.
Created attachment 127307 [details] Proposed patch The only explanation for the NPE on the line shown in the stack trace is that the report level was null when trying to report the match. The only possibility that this happens is that it has been reported while visiting the MemberDeclarationVisitor before. Theoretically, this is only possible when there's local type and this case was already protected before, but as there was a compiler error, I talked with David and it seems that in case of a statement recovery, this might happen... Hence, the null checking sounds like an acceptable patch to make the Search resilient for such compiler errors...
Released for 3.5M6 in HEAD stream.
Verified for 3.5M6
