Description bungeman 2008-11-24 15:41:08 EST

Build ID: WID6.2-20081119_0200

Steps To Reproduce:
I'm not sure if anyone will ever reproduce this again, but it did happen. Since this is non-deterministic, I can only make a best-guess.
1. Place a breakpoint at JavaModelManager.java:1833 between the test and the call to create a new Hashtable.
2. Create a Java project, add natures, set up the classpath, set the source directories, put some code in it, and build it.
3. Run things until, at some point, this.optionsCache becomes null after the test, but before the call.


More information:
java.lang.NullPointerException

at java.util.Hashtable.<init>(Unknown Source)

at org.eclipse.jdt.internal.core.JavaModelManager.getOptions(JavaModelManager.java:1833)

at org.eclipse.jdt.core.JavaCore.getOptions(JavaCore.java:3173)

at org.eclipse.jdt.internal.core.JavaProject.getOptions(JavaProject.java:1530)

at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.newCompiler(AbstractImageBuilder.java:500)

at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.<init>(AbstractImageBuilder.java:95)

at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.<init>(BatchImageBuilder.java:32)

at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildAll(JavaBuilder.java:253)

at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:173)

at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:633)

at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)

at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:170)

at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:201)

at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:253)

at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)

at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:256)

at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:218)

at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:360)

at org.eclipse.core.internal.resources.Project.internalBuild(Project.java:516)

at org.eclipse.core.internal.resources.Project.build(Project.java:94)

at com.ibm.wbimonitor.deploy.base.UDFContribution$3.run(UDFContribution.java:290)

at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1800)

at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1782)

at com.ibm.wbimonitor.deploy.base.UDFContribution.createSupportJar(UDFContribution.java:293)

at com.ibm.wbimonitor.deploy.base.UDFContribution.generateContribution(UDFContribution.java:137)

at com.ibm.wbimonitor.deploy.base.EarProjectGenerator.callGenerators(EarProjectGenerator.java:614)

at com.ibm.wbimonitor.deploy.base.EarProjectGenerator.run(EarProjectGenerator.java:455)

at com.ibm.wbimonitor.deploy.mmdeploy.MonitoringModelDeployOperation.generateCode(MonitoringModelDeployOperation.java:172)

at com.ibm.wbimonitor.deploy.mmdeploy.MonitoringModelDeployOperation.run(MonitoringModelDeployOperation.java:80)

at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) 

I happen to have the source code for jdt for this particular build, and the line indicated is

if (this.optionsCache != null) return new Hashtable(this.optionsCache);

Since this.optionsCache is a Hashtable, it appears that the only possible way this could happen is for another tread to have set this.optionsCache to null between the test and the call. Because this particular exception happened in a build, I don't have a whole lot of other information to provide, other than that the same build worked perfectly the next time it ran (with exactly the same code and setup).