Community
Participate
Working Groups
Using the latest 3.7 I-build. While self-hosting I have projects in my target workspace that use class file folders from my host IDE. I had compiliation errors showing that required classes could not be found. Expanding my "Plug-in Dependencies" classpath container, I found that the external class file folder appeared empty (but there are packages class files in it when I look in disk). When I attempted to refresh the project I got the following NPE: eclipse.buildId=I20100727-0800 java.version=1.6.0_18-ea java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US Framework arguments: -product org.eclipse.sdk.ide Command-line arguments: -product org.eclipse.sdk.ide -data C:\eclipse-dev\next-bench -dev file:C:/eclipse-dev/dev-3.7/.metadata/.plugins/org.eclipse.pde.core/Next Bench/dev.properties -debug C:\eclipse-dev\dev-3.7\.metadata\.plugins\org.eclipse.pde.core\Next Bench/.options -os win32 -ws win32 -arch x86 -clean -consoleLog Error Fri Jul 30 10:09:46 CDT 2010 An internal error occurred during: "Refreshing external folders". java.lang.NullPointerException at org.eclipse.jdt.internal.core.ExternalFoldersManager$RefreshJob.run(ExternalFoldersManager.java:387) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Created attachment 175585 [details] image of empty class file folder on classpath
This sounds very much like bug 320618, which also talks about classes not found through a linked folder, because no nodes from the linked folder are entered into the workspace's ElementTree. Could you try the patch I attached there?
The NPE might actually be due to the fix from bug 313153 which removed an "if (folder != null)". However, we should probably never get into that state where we get a null at this point?
(In reply to comment #3) > The NPE might actually be due to the fix from bug 313153 which removed > an "if (folder != null)". However, we should probably never get into > that state where we get a null at this point? Jay, please also review the fix for 313153.
*** Bug 322545 has been marked as a duplicate of this bug. ***
(In reply to comment #2) > This sounds very much like bug 320618, which also talks about classes > not found through a linked folder, because no nodes from the linked folder > are entered into the workspace's ElementTree. > > Could you try the patch I attached there? I think these two are different issues. In this case, it appears that the state of the external folders cache is corrupt. (In reply to comment #3) > The NPE might actually be due to the fix from bug 313153 which removed > an "if (folder != null)". However, we should probably never get into > that state where we get a null at this point? Indeed. What is interesting to us is the cause that leaves the external folder manager state as it has been here.
I just got hit by this in I20100817-0800, also while I was self-hosting. It happened to me immediately after I launched a target workspace and during the "Initializing Java Tooling" job. java.lang.NullPointerException at org.eclipse.jdt.internal.core.ExternalFoldersManager$RefreshJob.run(ExternalFoldersManager.java:387) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
(In reply to comment #7) > I just got hit by this in I20100817-0800, also while I was self-hosting. > > It happened to me immediately after I launched a target workspace and during > the "Initializing Java Tooling" job. > > > java.lang.NullPointerException > at > org.eclipse.jdt.internal.core.ExternalFoldersManager$RefreshJob.run(ExternalFoldersManager.java:387) > at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) Michael, I believe you will see this problem when you refresh the appropriate project or the workspace. Please confirm. Also can you attach the external folders project file, which you will find under: .metadata\.plugins\org.eclipse.jdt.core\.org.eclipse.jdt.core.external.folders\.project It would also help if you can check if any of the linked folders present in the external folder project file are missing.
Created attachment 177444 [details] requested .project file
(In reply to comment #8) > I believe you will see this problem when you refresh the appropriate project or > the workspace. Please confirm. Tried refreshing both and did not experience the problem again > Also can you attach the external folders project > file, which you will find under: > .metadata\.plugins\org.eclipse.jdt.core\.org.eclipse.jdt.core.external.folders\ > .project Done. > It would also help if you can check if any of the linked folders present in the > external folder project file are missing. All of the projects in the mentioned .project file are in my workspace, open and error free.
One of the hypothetical reasons is (as Stephan mentioned) the report in bug #320618. The addition of external folders entry might have been added only to the cache but not persisted (as put in bug 320618) and the cache might have been removed later during the clean-up. However, this still doesn't quite explain the exceptions during the initialization. For now, I will put back the null check that I removed as part of fix to bug 313153. If it's a different bug we will have to wait for it to manifest itself.
Created attachment 177918 [details] Patch Patch with the null check added back.
(In reply to comment #12) Patch looks good for me.
Released in HEAD for 3.7 M2.
Verified for 3.7M2 using build I20100909-1700
*** Bug 325399 has been marked as a duplicate of this bug. ***
I'm using Buckminster to build my products. Current I use version 3.6.1 of eclipse (just downloaded it). I'm getting the same exception during my build process and was wondering if this will be fixed for 3.6.x as well since the last comments only states for 3.7M2.
Just updated this evening from 3.6 to 3.6.1 and started receiving this error. I am unaware of any external folders I am using. The error displays itself several times during startup, and is quite annoying. Message: An internal error occurred during: "Refreshing external folders". Exception Stack Trace: java.lang.NullPointerException at org.eclipse.jdt.internal.core.ExternalFoldersManager$RefreshJob.run(ExternalFoldersManager.java:387) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) I do not have the folder referenced in Comment #8 (.metadata\.plugins\org.eclipse.jdt.core\.org.eclipse.jdt.core.external.folders\.project) This error makes starting Eclipse unpleasant.
After upgrading to 3.6.1 this morning I experience the same annoying problem. This morning there was no external folder configured. Now there is one (a source attachment to a lib), but the problem didn't change.
Jay, please open a new bug report to target 3.6.2 and try to see how this problem suddenly appears in 3.6.x stream. Thanks.
I am having this error message pop up every time I save a file in my workspace. I am using Eclipse 3.6.1 and the Android DDMS Plugin 0.9.9. I'd like to know when this fix will be made available to the public since it's quite annoying to have to work like this. I also accidentally commented on bug 313153, sorry about that.
I found that a source attachment was the cause of the issue for me. So I removed the source attachment for now, and my error message is not popping up every time I save now. So my workaround for the issue is to go into 'Configure Build Path' look at my 'Libraries' tab, and remove any 'Source attachements' from JARs.
I opened bug 326434 to track this issue with 3.6.1. Please post all comments to this new bug report.
I'm getting this same problem on Helios SR1. In my case: 1. open eclipse 2. team/update one of my projects 3. got this error I see the fix is targeted for 3.7. I hope it will find it's way into 3.6 as well. Michael Giroux eclipse.buildId=M20100909-0800 java.version=1.6.0_21 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US Framework arguments: -product org.eclipse.epp.package.jee.product Command-line arguments: -os win32 -ws win32 -arch x86 -product org.eclipse.epp.package.jee.product -data c:/EclipseWorkspace3.6/Trunk Error Wed Oct 13 06:26:22 GMT-07:00 2010 An internal error occurred during: "Refreshing external folders". java.lang.NullPointerException at org.eclipse.jdt.internal.core.ExternalFoldersManager$RefreshJob.run(ExternalFoldersManager.java:387) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
(In reply to comment #24) > I'm getting this same problem on Helios SR1. In my case: > 1. open eclipse > 2. team/update one of my projects > 3. got this error > > I see the fix is targeted for 3.7. I hope it will find it's way into 3.6 as > well. Please check bug 326434 for a resolution in 3.6.x.
Verifying Neal Sanche's comment 22 that the source attachment seems to be the problem. After checking out a project having the eclipse config attached, I got the NPE at line 387 every time I hit F5. After removing all source attachments (which pointed somewhere completely "random" for my box), the refresh worked.
Finally, I am able to reproduce this problem. As observed in bug 321358, it is indeed a problem with the source attachment, which points to an invalid folder. And it has nothing to do Android development environment. This is the scenario: Note: I backed out the changes made as part of this bug fix. 1. Create workspace/project and a library entry with a source attachment that refers to a folder that doesn't exist. 2. Now create and open a new workspace, import the project created in step 1 (don't know if it matters but don't copy the project contents) 3. As the project gets imported and refreshed, the NPE is thrown. I believe other scenarios are similar too. This is what I found in my investigation. In the cases when the external source attachment gets created outside the current workspace (or the .metadata is deleted or the external folder project file doesn't contain the required entries), and if the source attachment is pointing to an invalid location, the folder doesn't get added to the list of known external folders. If the folder is an external class path entry, it gets added to the folders list and eventually to the external folder project file from JavaProject#addToResult -> externalFoldersManager.addFolder(). However, the source attachments don't get such a chance. This is okay, since the external folder doesn't exist anyway. So, whatever fix made already should be good enough.
*** Bug 328550 has been marked as a duplicate of this bug. ***
*** Bug 330880 has been marked as a duplicate of this bug. ***
I'm getting this error even when I remove everything from Java Build Path -> Source. Also there is nothing external linked in my project. In another project everything is OK, unfortunately I fail to see the crucial difference. It would help if the error message included name of the troubled folder/link/resource/... Version: Helios Service Release 1 Build id: 20100917-0705
Replicated in Eclipse Helios Version: 3.6.1 Build id: M20100909-0800, Windows7 64bit. It stopped raising NPE by closing the project and opeinig it again. Definitively has something to do with source folders.
Encountered this same issue again in Indigo (Indigo Service Release 1 Build id: 20110916-0149) "Tree element '/.org.eclipse.jdt.core.external.folders/.project' not found." Computer crashed (Win 7) while debugging an Android application. Although the computer crash was apparently due to a Flash video exception with the hardware video driver - totally unrelated to Eclipse or Android. Error occurred on reopening Eclipse and again during basically every other action .. - turned of "Build Automatically" - performed a "Clean All" on projects - closed all projects - closed Eclipse - reopened Eclipse (no errors) - reopened projects (no errors) - Re-enabled "Build Automatically" ... did NOT manually build ... just re-enabled auto build Built fine, and the application integrity looks fine too - aside from my own bugs ... shame those weren't magically fixed too :P
(In reply to comment #32) > Encountered this same issue again in Indigo > (Indigo Service Release 1 Build id: 20110916-0149) ... > > Built fine, and the application integrity looks fine too - aside from my own > bugs ... shame those weren't magically fixed too :P Sorry, I didn't quite get it. Are you saying that things are alright now?
