Community
Participate
Working Groups
Build Identifier: I20100608-0911 "Clean build" on plug-in project with incomplete(?) JDT compiler settings causes NPE in BuildErrorReporter. See stack trace below. In the compiler properties page of the related project we checked "Enable project specific setting" and "Use compliance from execution environment 'J2SE-1.5'...". In MANIFEST.MF "Bundle-RequiredExecutionEnvironment: J2SE-1.5". However, in the "org.eclipse.jdt.core.prefs' file we found only the entry "org.eclipse.jdt.core.compiler.compliance=1.5". The entries "org.eclipse.jdt.core.compiler.source=1.5" and "org.eclipse.jdt.core.compiler.codegen.targetPlatform=1.5" have been lacking. Adding "org.eclipse.jdt.core.compiler.source=1.5" has fixed the problem. eclipse.buildId=I20100608-0911 java.version=1.6.0_16 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US Command-line arguments: -os win32 -ws win32 -arch x86 Error Tue Jul 13 09:42:09 CEST 2010 Errors running builder 'Plug-in Manifest Builder' on project 'de.visualrules.magic'. java.lang.NullPointerException at org.eclipse.pde.internal.core.builders.BuildErrorReporter.findMatchingEE(BuildErrorReporter.java:509) at org.eclipse.pde.internal.core.builders.BuildErrorReporter.validateExecutionEnvironment(BuildErrorReporter.java:322) at org.eclipse.pde.internal.core.builders.BuildErrorReporter.validateBuild(BuildErrorReporter.java:247) at org.eclipse.pde.internal.core.builders.BuildErrorReporter.validate(BuildErrorReporter.java:139) at org.eclipse.pde.internal.core.builders.ErrorReporter.validateContent(ErrorReporter.java:127) at org.eclipse.pde.internal.core.builders.ManifestConsistencyChecker.validateBuildProperties(ManifestConsistencyChecker.java:316) at org.eclipse.pde.internal.core.builders.ManifestConsistencyChecker.validateProject(ManifestConsistencyChecker.java:231) at org.eclipse.pde.internal.core.builders.ManifestConsistencyChecker.build(ManifestConsistencyChecker.java:157) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:629) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:172) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:203) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:255) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:258) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:311) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:343) at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:144) at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:242) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) Reproducible: Always
PDE does not account for null being returned from: org.eclipse.jdt.core.IJavaProject.getOption(String, boolean)
I am adding a new problem marker for this situation. It won't have any quick fix. "The project specific Java compiler settings are enabled but could not read the values." suggest me a better message.
Actually, when the source or target level is missing, could we just retrieve it from the "default" settings? - i.e. project.getOption(JavaCore.COMPILER_SOURCE, *true*) Then we're guarenteed to get a non-null value and that is also what the UI shows as the value when you open the preference page. Does this make sense?
(In reply to comment #3) > Actually, when the source or target level is missing, could we just retrieve it > from the "default" settings? - i.e. This is how we do it elsewhere in PDE. As long as a Java project exists, there should always be a setting. If there are no project specific settings, we should default to the global settings.
> Then we're guarenteed to get a non-null value and that is also what the UI > shows as the value when you open the preference page. > > Does this make sense? Right, but here the user is under impression that the project specific settings are enforced. If we pick the default settings then the build.properties will get entries as per default settings and not the project specific ones. This could be a problem at export time?
(In reply to comment #5) > > Then we're guarenteed to get a non-null value and that is also what the UI > > shows as the value when you open the preference page. > > > > Does this make sense? > Right, but here the user is under impression that the project specific settings > are enforced. If we pick the default settings then the build.properties will > get entries as per default settings and not the project specific ones. This > could be a problem at export time? Yes... but in this case the code already knows the user has project specific settings. They just appear to be broken... i.e. they have a compliance setting and a target level, but are missing the source level. I'm not sure how one would get into this state (I was able to do it by deleting a line from the .prefs file in the .settings directory). So, in this case, reverting to the default value seems reasonable. Else we're reporting an error about an invalid JDT preference file, which isn't really PDE's job.
(In reply to comment #6) > I'm not sure how one > would get into this state (I was able to do it by deleting a line from the > .prefs file in the .settings directory). I also don't know why the 'source' and 'targetPlatform' entries are missing. The 'compliance' entry was added at September 2009. Mabye the beahviour of an older JDT Version? The developer of the plugin is currently on vacation. I'll ask him soon if he has deleted the entries manually. We have checked the "Use compliance from execution environment 'J2SE-1.5'..." option. So, falling back to the execution environments default source and target would be fine. But maybe it's more a bug of JDT then PDE and 'project.getOption(JavaCore.COMPILER_SOURCE, *true*)' should handle this for you.
Created attachment 174262 [details] Patch
Fixed in HEAD Since theres a workaround (fix the prefs) I am marking it for 3.7 M1. Let us know if you need it for 3.6.1.
Thx, workaround works fine. Don't need fix on 3.6.1.
Verified in I20100802-1800.
