Community
Participate
Working Groups
Build ID: 3.4RC4 Steps To Reproduce: Repeatable with Sun and IBM 1.6 vms IES target 1. Use workspace preferences to switch targets More information: An internal error occurred during: "Resetting Target Platform". java.lang.NullPointerException at org.eclipse.pde.internal.core.JavadocLocationManager.getEntry(JavadocLocationManager.java:52) at org.eclipse.pde.internal.core.JavadocLocationManager.getJavadocLocation(JavadocLocationManager.java:39) at org.eclipse.pde.internal.core.PDEClasspathContainer.getClasspathAttributes(PDEClasspathContainer.java:123) at org.eclipse.pde.internal.core.PDEClasspathContainer.addExternalPlugin(PDEClasspathContainer.java:69) at org.eclipse.pde.internal.core.RequiredPluginsClasspathContainer.addPlugin(RequiredPluginsClasspathContainer.java:255) at org.eclipse.pde.internal.core.RequiredPluginsClasspathContainer.addDependency(RequiredPluginsClasspathContainer.java:229) at org.eclipse.pde.internal.core.RequiredPluginsClasspathContainer.addDependency(RequiredPluginsClasspathContainer.java:213) at org.eclipse.pde.internal.core.RequiredPluginsClasspathContainer.computePluginEntries(RequiredPluginsClasspathContainer.java:129) at org.eclipse.pde.internal.core.RequiredPluginsClasspathContainer.getClasspathEntries(RequiredPluginsClasspathContainer.java:88) at org.eclipse.jdt.internal.core.ClasspathEntry.validateClasspathEntry(ClasspathEntry.java:1567) at org.eclipse.jdt.internal.core.ClasspathValidation.validate(ClasspathValidation.java:69) at org.eclipse.jdt.internal.core.ChangeClasspathOperation.classpathChanged(ChangeClasspathOperation.java:51) at org.eclipse.jdt.internal.core.SetContainerOperation.executeOperation(SetContainerOperation.java:112) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:709) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1800) at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:775) at org.eclipse.jdt.core.JavaCore.setClasspathContainer(JavaCore.java:4703) at org.eclipse.pde.internal.core.PluginModelManager.updateAffectedEntries(PluginModelManager.java:239) at org.eclipse.pde.internal.core.PluginModelManager.modelsChanged(PluginModelManager.java:164) at org.eclipse.pde.internal.core.PluginModelManager.resetState(PluginModelManager.java:853) at org.eclipse.pde.internal.core.TargetPlatformResetJob.run(TargetPlatformResetJob.java:38) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
This only seems to happen the first time the target is set (or reset?). Once the target has been set, and failed because of the error, it is possible to make the workspace "sane" by reloading and reapplying the target again.
Race condition between the reset job and getting javadoc locations. Almost identical to bug 228297. Can be easily solved by synchronizing the getEntry method instead of the initialize method, so that the location map can't be reset in the middle of the lookup. Only concern is that concurrent lookups would be slowed down as they would have to wait for each other. To avoid this, a read/write lock could be used (though Java didn't provide an implementation until 1.5).
That seems to do the trick.
Created attachment 105097 [details] patch with synchronized keyword for completeness... patch implementing simple synchronization
*** Bug 240376 has been marked as a duplicate of this bug. ***
Consider fixing in M1.
Did some more testing/investigating and it's unlikely that entries will be requested from multiple threads at the same time (typically done sequentially in the same thread). Even if there are multiple threads, the performance difference will be undetectable. Rather than creating a custom implementation of a read/write lock, it's safer to go with the simple solution. Fixed in HEAD by adding the synchronize.
fixed in 3.4.1 too
