Bug 260731 - [search] NPE thrown by JavaSearchScope.normalize after clicking Open Type tool
Summary: [search] NPE thrown by JavaSearchScope.normalize after clicking Open Type tool
Status: VERIFIED WONTFIX
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.3.2   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.5 M6   Edit
Assignee: Frederic Fusier CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-01-12 11:01 EST by Simon Archer CLA
Modified: 2009-03-09 12:03 EDT (History)
4 users (show)

See Also:


Attachments
Screen shot of the installed JDT plugins. (20.01 KB, image/gif)
2009-01-12 11:01 EST, Simon Archer CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Simon Archer CLA 2009-01-12 11:01:57 EST
Created attachment 122283 [details]
Screen shot of the installed JDT plugins.

This looks similar to bug 178459 that was fixed for Eclipse 3.3, but I am seeing this in Eclipse 3.3.2.

I simply clicked the Open Type dialog and pasted in a type name.

!ENTRY org.eclipse.core.jobs 4 2 2009-01-12 10:52:51.656
!MESSAGE An internal error occurred during: "Cache refresh".
!STACK 0
java.lang.NullPointerException
	at org.eclipse.jdt.internal.core.search.JavaSearchScope.normalize(JavaSearchScope.java:506)
	at org.eclipse.jdt.internal.core.search.JavaSearchScope.add(JavaSearchScope.java:268)
	at org.eclipse.jdt.internal.core.search.JavaSearchScope.rehash(JavaSearchScope.java:609)
	at org.eclipse.jdt.internal.core.search.JavaSearchScope.add(JavaSearchScope.java:299)
	at org.eclipse.jdt.internal.core.search.JavaSearchScope.add(JavaSearchScope.java:176)
	at org.eclipse.jdt.internal.core.search.JavaWorkspaceScope.initialize(JavaWorkspaceScope.java:84)
	at org.eclipse.jdt.internal.core.search.JavaWorkspaceScope.enclosingProjectsAndJars(JavaWorkspaceScope.java:63)
	at org.eclipse.jdt.internal.core.search.IndexSelector.initializeIndexLocations(IndexSelector.java:120)
	at org.eclipse.jdt.internal.core.search.IndexSelector.getIndexLocations(IndexSelector.java:201)
	at org.eclipse.jdt.internal.core.search.JavaSearchParticipant.selectIndexes(JavaSearchParticipant.java:112)
	at org.eclipse.jdt.internal.core.search.PatternSearchJob.getIndexes(PatternSearchJob.java:80)
	at org.eclipse.jdt.internal.core.search.PatternSearchJob.ensureReadyToRun(PatternSearchJob.java:51)
	at org.eclipse.jdt.internal.core.search.processing.JobManager.performConcurrentJob(JobManager.java:177)
	at org.eclipse.jdt.internal.core.search.BasicSearchEngine.searchAllTypeNames(BasicSearchEngine.java:778)
	at org.eclipse.jdt.core.search.SearchEngine.searchAllTypeNames(SearchEngine.java:697)
	at org.eclipse.jdt.internal.ui.dialogs.FilteredTypesSelectionDialog$ConsistencyRunnable.refreshSearchIndices(FilteredTypesSelectionDialog.java:697)
	at org.eclipse.jdt.internal.ui.dialogs.FilteredTypesSelectionDialog$ConsistencyRunnable.run(FilteredTypesSelectionDialog.java:683)
	at org.eclipse.jdt.internal.ui.dialogs.FilteredTypesSelectionDialog.reloadCache(FilteredTypesSelectionDialog.java:723)
	at org.eclipse.ui.dialogs.FilteredItemsSelectionDialog$RefreshCacheJob.run(FilteredItemsSelectionDialog.java:1412)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
Comment 1 Frederic Fusier CLA 2009-01-14 06:13:37 EST
I don't see other explanation than a concurrency issue while building the JavaWorkspaceScope to explain this NPE. We had other troubles around this area which was fixed in 3.4 (see bug 182738) but the fix is too big to be backported like this in R3_3_maintenance stream.

I'll figure out what would be the best solution to fix this issue in this stream...
Comment 2 Simon Archer CLA 2009-01-14 08:47:54 EST
If this code has already been improved in a later release then I would suggest that we do nothing to fix it in 3.3.2. This problem is not one I see often, so I'd hate for you to spend time on fixing it, especially if it's already fixed in 3.4. Thanks.
Comment 3 Frederic Fusier CLA 2009-02-02 05:10:15 EST
(In reply to comment #2)
> If this code has already been improved in a later release then I would suggest
> that we do nothing to fix it in 3.3.2. This problem is not one I see often, so
> I'd hate for you to spend time on fixing it, especially if it's already fixed
> in 3.4. Thanks.
> 
=> close as WONTFIX
Comment 4 David Audel CLA 2009-03-09 12:03:05 EDT
Verified for 3.5M6