Bug 211962 - [search] NullPointerException when typing search pattern in open type
Summary: [search] NullPointerException when typing search pattern in open type
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.2   Edit
Hardware: PC Mac OS X - Carbon (unsup.)
: P3 critical (vote)
Target Milestone: 3.3.2   Edit
Assignee: Frederic Fusier CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 212322 240519 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-12-05 02:49 EST by Alexander Sparkowsky CLA
Modified: 2008-07-14 02:58 EDT (History)
5 users (show)

See Also:
philippe_mulet: pmc_approved+


Attachments
Proposed patch (5.47 KB, patch)
2008-01-09 07:23 EST, Frederic Fusier CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Sparkowsky CLA 2007-12-05 02:49:40 EST
Build ID: M20071129-1100

Steps To Reproduce:
1. Open "Open Type" dialog (cmd-shift-T)
2. Start typing a search pattern
3. Each key stroke produces a NullPointerException. No search results are shown


More information:
java.lang.NullPointerException
        at org.eclipse.jdt.internal.core.search.JavaSearchScope.packageFragmentRoot(JavaSearchScope.java:589)
        at org.eclipse.jdt.internal.core.search.TypeNameMatchRequestorWrapper.createTypeFromJar(TypeNameMatchRequestorWrapper.java:124)
        at org.eclipse.jdt.internal.core.search.TypeNameMatchRequestorWrapper.acceptType(TypeNameMatchRequestorWrapper.java:108)
        at org.eclipse.jdt.internal.core.search.BasicSearchEngine$2.acceptIndexMatch(BasicSearchEngine.java:767)
        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:279)
        at org.eclipse.jdt.internal.core.search.BasicSearchEngine.searchAllTypeNames(BasicSearchEngine.java:778)
        at org.eclipse.jdt.core.search.SearchEngine.searchAllTypeNames(SearchEngine.java:781)
        at org.eclipse.jdt.internal.ui.dialogs.FilteredTypesSelectionDialog.fillContentProvider(FilteredTypesSelectionDialog.java:593)
        at org.eclipse.ui.dialogs.FilteredItemsSelectionDialog$FilterJob.filterContent(FilteredItemsSelectionDialog.java:2083)
        at org.eclipse.ui.dialogs.FilteredItemsSelectionDialog$FilterJob.internalRun(FilteredItemsSelectionDialog.java:2025)
        at org.eclipse.ui.dialogs.FilteredItemsSelectionDialog$FilterJob.doRun(FilteredItemsSelectionDialog.java:1997)
        at org.eclipse.ui.dialogs.FilteredItemsSelectionDialog$FilterJob.run(FilteredItemsSelectionDialog.java:1984)
        at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
Comment 1 Frederic Fusier CLA 2007-12-05 16:13:16 EST
Could you give me a little bit information on your workspace setup?
Especially if there are some projects with classpath issues (unresolvde jar files or class folders)?
Comment 2 Frederic Fusier CLA 2007-12-09 07:02:02 EST
JavaSearchScope is supposed to be only made of projects and jars which are on the classpath and so, all resources found inside the JavaSearchScope should have a corresponding Java Element.

I definitely need more information to reproduce your issue to have a chance to understand why a JavaCore.create(...) method has returned null on a target got from the JSS...

If this problem is really critical, we can think about a workaround in the maintenance stream for 3.3.2 by adding a null check and log some information, but before doing this, I really want to figure out what exactly happens there.
Comment 3 Alexander Sparkowsky CLA 2007-12-09 09:02:27 EST
Sorry, I've been busy the last days...

What I initialy did was that I used my existing 3.3.1(.1) workspace with the 3.3.2 mainstreambuild because 3.1.1 is useless on Mac 10.5.

Regarding the workspace setup:
- Since I had some plugins installed that are not part of standard distribution eclipse could not restore the initial workspace layout (this may not have anything to do with this issue)
- There are a lot of projects in my workspace that DO have unresolved classpath entries


Comment 4 Frederic Fusier CLA 2007-12-09 09:36:15 EST
Thanks for your feedback.

Can you reproduce this NPE systematically? If so, have tried to refresh your workspace?
Comment 5 Alexander Sparkowsky CLA 2007-12-09 10:16:12 EST
It happens all the time I try to search. I'm not sure what you mean by refresh workspace. I've re-build all projects and I've marked all projects and hit F5.

Comment 6 Frederic Fusier CLA 2007-12-09 10:43:41 EST
(In reply to comment #5)
> It happens all the time I try to search. I'm not sure what you mean by refresh
> workspace. I've re-build all projects and I've marked all projects and hit F5.
> 
I was talking about the File->Refresh... menu item in the Package Explorer. This will synchronize all the resources in your workspace with the file system and send all necessary events (which should update the Java Search scope)...
Comment 7 Alexander Sparkowsky CLA 2007-12-09 13:49:55 EST
I refreshed the workspace in the package explorer like you described. This
didn't change anything. Some of the projects are closed so I think they will
not be refreshed. But they won't be searched either I think.
Comment 8 Frederic Fusier CLA 2007-12-10 09:18:58 EST
*** Bug 212322 has been marked as a duplicate of this bug. ***
Comment 9 Alexander Maletz CLA 2007-12-10 10:21:23 EST
(In reply to comment #1)
> Could you give me a little bit information on your workspace setup?
> Especially if there are some projects with classpath issues (unresolvde jar
> files or class folders)?
> 

This exception happens to me as well, but there NO classpath issues on workspace (actually - no other errors as well)
Many JARS are used, they stored in separate project and referenced from others.
No closed projects on workspace.
Comment 10 Frederic Fusier CLA 2008-01-07 11:21:57 EST
(In reply to comment #9)
> 
> This exception happens to me as well, but there NO classpath issues on
> workspace (actually - no other errors as well)
> Many JARS are used, they stored in separate project and referenced from others.
> No closed projects on workspace.
> 
What is your build ID?
Comment 11 Frederic Fusier CLA 2008-01-07 11:26:32 EST
It looks like a side effect of bug 204652 workaround released in R3_3_maintenance stream...
Comment 12 Frederic Fusier CLA 2008-01-07 11:56:03 EST
(In reply to comment #10)
> What is your build ID?
> 
I also would like to know what is your OS?
Comment 13 Frederic Fusier CLA 2008-01-08 03:50:15 EST
Cannot be targeted for 3.4M5 as this problem is related to a specific change in the R3_3_maintenance stream...
Comment 14 Alexander Maletz CLA 2008-01-08 04:25:06 EST
(In reply to comment #12)
> (In reply to comment #10)
> > What is your build ID?
> > 
> I also would like to know what is your OS?
> 

Ok
Here are configuration details:
OS is WinXP Sp2

*** Platform Details:

*** System properties:
awt.toolkit=sun.awt.windows.WToolkit
eclipse.buildId=M20071219-0800
eclipse.commands=-os
win32
-ws
win32
-arch
x86
-showsplash
D:\bin\eclipse332\\plugins\org.eclipse.platform_3.3.3.R33x_v20071217\splash.bmp
-launcher
D:\bin\eclipse332\eclipse.exe
-name
Eclipse
--launcher.library
D:\bin\eclipse332\plugins\org.eclipse.equinox.launcher.win32.win32.x86_1.0.2.R33x_v20071005\eclipse_1021.dll
-startup
D:\bin\eclipse332\plugins\org.eclipse.equinox.launcher_1.0.1.R33x_v20070828.jar
-vm
d:\jdk1.6\bin\..\jre\bin\client\jvm.dll
eclipse.ee.install.verify=false
eclipse.product=org.eclipse.sdk.ide
eclipse.startTime=1199784108640
eclipse.vm=d:\jdk1.6\bin\..\jre\bin\client\jvm.dll
eclipse.vmargs=-Xms40m
-Xmx256m
-XX:MaxPermSize=256m
-Djava.class.path=D:\bin\eclipse332\plugins\org.eclipse.equinox.launcher_1.0.1.R33x_v20070828.jar
eof=eof
file.encoding=Cp1252
file.encoding.pkg=sun.io
file.separator=\
Comment 15 Frederic Fusier CLA 2008-01-09 07:23:59 EST
Created attachment 86457 [details]
Proposed patch

The patch just adds a null check after the JavaCore.create(IResource) call to verify that the package fragment root can be computed safely from the IJavaElement.

Note that I was able to reproduce the NPE on Windows OS with an external library specified in the classpath entry without any device...

Test case added in JavaSearchMultplieProjectTests.
Comment 16 Frederic Fusier CLA 2008-01-09 07:27:43 EST
Philippe, can this fix go into 3.3.2?

The fix is more than safe (just a null check) and, even if the projects setup looks specific, it already occurs for two users. In this case, the Open Type does no longer work for the user without any possible workaround...
Comment 17 Alexander Sparkowsky CLA 2008-01-09 07:32:12 EST
This would be very nice. I'v learned to use eclipse without OpenType but it's a real pain!
Comment 18 Frederic Fusier CLA 2008-01-09 07:57:39 EST
(In reply to comment #17)
> This would be very nice. I'v learned to use eclipse without OpenType but it's a
> real pain!
> 
In fact there's a possible workaround but you need to modify your workspace projects setup...

First, you need to find the internal JAR files put in a non-Java project of your workspace which have the same path than the external JAR used in the build pathes of your Java projects.

Here's a simple example:
 - the external JAR file:
   /usr/tmp/lib.jar
 - the workspace:
   /workspace
     + usr
       + tmp
         + lib.jar
     + P1
   where 'usr' is a non-Java project in your workspace '/workspace' and
   the Java project 'P1' has the external JAR file "/usr/tmp/lib.jar' on its 
   classpath.

Second, to fix the issue, just remove the internal jar file 'lib.jar' from the workspace or close the non-Java project 'usr'. Then, the Open Type should work again properly...
Comment 19 Philipe Mulet CLA 2008-01-15 05:30:50 EST
+1 for 3.3.2
Comment 20 Frederic Fusier CLA 2008-01-15 05:32:14 EST
Released for 3.3.2 in R3_3_maintenance stream.
Comment 21 Maxime Daniel CLA 2008-01-24 05:08:39 EST
Verified for 3.3.2 using build M20080123-0800.
Comment 22 Dani Megert CLA 2008-07-14 02:58:51 EDT
*** Bug 240519 has been marked as a duplicate of this bug. ***