Bugzilla – Full Text Bug Listing
| Summary: | NPE in Plug-in Manifest Builder | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] PDE | Reporter: | Bernd Vogt <bernd.vogt> | ||||
| Component: | UI | Assignee: | Ankur Sharma <ankur_sharma> | ||||
| Status: | VERIFIED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | ankur_sharma, curtis.windatt.public, darin.eclipse, robert.klaus | ||||
| Version: | 3.6 | ||||||
| Target Milestone: | 3.7 M1 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Bernd Vogt
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. |