Community
Participate
Working Groups
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)
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)?
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.
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
Thanks for your feedback. Can you reproduce this NPE systematically? If so, have tried to refresh your workspace?
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.
(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)...
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.
*** Bug 212322 has been marked as a duplicate of this bug. ***
(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.
(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?
It looks like a side effect of bug 204652 workaround released in R3_3_maintenance stream...
(In reply to comment #10) > What is your build ID? > I also would like to know what is your OS?
Cannot be targeted for 3.4M5 as this problem is related to a specific change in the R3_3_maintenance stream...
(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=\
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.
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...
This would be very nice. I'v learned to use eclipse without OpenType but it's a real pain!
(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...
+1 for 3.3.2
Released for 3.3.2 in R3_3_maintenance stream.
Verified for 3.3.2 using build M20080123-0800.
*** Bug 240519 has been marked as a duplicate of this bug. ***