Community
Participate
Working Groups
This is similar, but not equal to bug 171359 and bug 161577 . In my dev workspace , I choose the 'open type' button in the toolbar then start typing in the search field and an error pops up with the message: An internal error occurred during: "Items filtering". The error pops out only for some types (it works if I start typing 'f' but not with 's' or 'd' ) and it depends on what projects are open in my workspace ( I suspect that some specific class names cause trouble ... I will update the bug if I find which class name is causing the problem ). This is the error stack trace : java.lang.NullPointerException at org.eclipse.jdt.internal.core.search.JavaSearchScope.packageFragmentRoot(JavaSearchScope.java:592) at org.eclipse.jdt.internal.core.search.TypeNameMatchRequestorWrapper.createTypeFromPath(TypeNameMatchRequestorWrapper.java:156) at org.eclipse.jdt.internal.core.search.TypeNameMatchRequestorWrapper.acceptType(TypeNameMatchRequestorWrapper.java:107) at org.eclipse.jdt.internal.core.search.BasicSearchEngine$2.acceptIndexMatch(BasicSearchEngine.java:768) at org.eclipse.jdt.internal.core.search.matching.InternalSearchPattern.acceptMatch(InternalSearchPattern.java:45) at org.eclipse.jdt.internal.core.search.matching.InternalSearchPattern.findIndexMatches(InternalSearchPattern.java:89) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.findIndexMatches(MatchLocator.java:325) at org.eclipse.jdt.internal.core.search.PatternSearchJob.search(PatternSearchJob.java:114) at org.eclipse.jdt.internal.core.search.PatternSearchJob.execute(PatternSearchJob.java:64) at org.eclipse.jdt.internal.core.search.processing.JobManager.performConcurrentJob(JobManager.java:265) at org.eclipse.jdt.internal.core.search.BasicSearchEngine.searchAllTypeNames(BasicSearchEngine.java:779) at org.eclipse.jdt.core.search.SearchEngine.searchAllTypeNames(SearchEngine.java:781) at org.eclipse.jdt.internal.ui.dialogs.FilteredTypesSelectionDialog.fillContentProvider(FilteredTypesSelectionDialog.java:479) at org.eclipse.ui.dialogs.FilteredItemsSelectionDialog$FilterJob.filterContent(FilteredItemsSelectionDialog.java:1945) at org.eclipse.ui.dialogs.FilteredItemsSelectionDialog$FilterJob.internalRun(FilteredItemsSelectionDialog.java:1882) at org.eclipse.ui.dialogs.FilteredItemsSelectionDialog$FilterJob.doRun(FilteredItemsSelectionDialog.java:1853) at org.eclipse.ui.dialogs.FilteredItemsSelectionDialog$FilterJob.run(FilteredItemsSelectionDialog.java:1840) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58) These are the session data : eclipse.buildId=I20070323-1616 java.version=1.6.0-dp java.vendor=Apple Computer, Inc. BootLoader constants: OS=macosx, ARCH=x86, WS=carbon, NL=en_US Framework arguments: -startup /Users/battlehorse/bin/eclipse3.3/Eclipse.app/Contents/MacOS/../../../plugins/org.eclipse.equinox.launcher_1.0.0.v20070319.jar -keyring /Users/battlehorse/.eclipse_keyring -showlocation Command-line arguments: -os macosx -ws carbon -arch x86 -startup /Users/battlehorse/bin/eclipse3.3/Eclipse.app/Contents/MacOS/../../../plugins/org.eclipse.equinox.launcher_1.0.0.v20070319.jar -keyring /Users/battlehorse/.eclipse_keyring -consoleLog -showlocation
The element returned by JavaCore.create(IResource) might be null as specified in the javadoc comment. I should have take this possibility into account and protect the line after in JavaSearchScope (ie. line 593) for such a case... However, I really would like to know which kind of resource can make this happen. It would be really helpful if you found the offending one or if you could send me the workspace for debugging...
Can you also run Eclipse with the -debug option and put a .options file in your Eclipse install directory with the following content: # 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 You should get a trace in the console of the search engine activity.
I was able to reproduce the NPE using the wksp you sent me, thanks for your time. Problem comes from your project classpath which both defines the 'bin' folder as the output and as a class folder. This is not supposed to be a valid build path and you cannot set it using the Java Build Path preference page... However, as user can modify .classpath by hand, we obviously should not trap into a NPE when this configuration is set. I will fix that issue and will also open a separate bug to add a marker for this specific problem while validating the classpath... The good news is that you have an easy workaround to avoid this NPE, just remove the unnecessary class folder 'bin' entry. I tried it and it works well after :-)
You are right, removing the additional entry in the classpath fixes the problem. However, the statement 'you cannot set it using the Java Build Path preference page' is not entirely right. Even if I can set it from the preference page, I can still do it from plugin.xml/MANIFEST.MF editor (adding the bin/ folder in the classpath section of the 'Runtime' tab ) and no errors nor warnings are raised. Thanks for your (extremely rapid) help .
(In reply to comment #4) > You are right, removing the additional entry in the classpath fixes the > problem. > However, the statement 'you cannot set it using the Java Build Path preference > page' is not entirely right. Even if I can set it from the preference page, I > can still do it from plugin.xml/MANIFEST.MF editor (adding the bin/ folder in > the classpath section of the 'Runtime' tab ) and no errors nor warnings are > raised. > It's not exactly the same configuration than the project in your workspace, as doing this you add the output location as a source folder. This configuration is valid (same as when your project has not explicit source folder, project folder is both source folder and output location). But I agree that doing this, you get the NPE as well, so we now have a simple scenario to reproduce the bug: 1) Create a new Plug-in project, let's say 'P' 2) Create a new class in source folder, let's say 'Test' 3) Switch off auto build or if it was already OFF, then build the project 'P' 4) Delete the source file Test.java in src 5) Open project properties, select 'Java Build Path' page and 'Source Folder' tab and add the bin folder as source folder 6) Open Type dialog and enter 'T' => you get the NPE! > Thanks for your (extremely rapid) help . > You're welcome
Sorry, the scenario was boggus, as I finally do not get the NPE with it. Step 5 should be instead: 5) Open .classpath, add following line and save it: <classpathentry kind="lib" path="bin"/>
Released for 3.3 M7 in HEAD stream. Change was done in JavaModelManager.create(IFolder, IJavaProject): remove final test to see if the folder confilcts with output location. Test case added in JavaSearchScopeTests#testBug179199()
*** Bug 182372 has been marked as a duplicate of this bug. ***
Verified for 3.3M7 with I20070427-0010
