Bugzilla – Full Text Bug Listing
| Summary: | NullPointerException in JUnitPreferencesConstants.parseList() | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Steffen Pingel <steffen.pingel> |
| Component: | Compendium | Assignee: | equinox.compendium-inbox <equinox.compendium-inbox> |
| Status: | CLOSED DUPLICATE | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | daniel_megert, Olivier_Thomann, remy.suen |
| Version: | 4.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
|
Description
Steffen Pingel
I'll take a look. Caused by bad fix for bug 387898. I reopened said bug. *** This bug has been marked as a duplicate of bug 387898 *** (In reply to comment #2) > Caused by bad fix for bug 387898. I reopened said bug. Thanks for finding the cause so quickly, Dani. I was wondering if a different default value should be passed in as a parameter? While we expect the rest of the system to work (with JunitPreferenceInitializer properly defining a value in the preferences), would it be better to just play it safe here given that the return value is directly passed into StringTokenizer? (In reply to comment #3) > (In reply to comment #2) > > Caused by bad fix for bug 387898. I reopened said bug. > > Thanks for finding the cause so quickly, Dani. > > I was wondering if a different default value should be passed in as a > parameter? While we expect the rest of the system to work (with > JunitPreferenceInitializer properly defining a value in the preferences), > would it be better to just play it safe here given that the return value is > directly passed into StringTokenizer? No. We might never have discovered this bug otherwise. (In reply to comment #4) > (In reply to comment #3) > > I was wondering if a different default value should be passed in as a > > parameter? While we expect the rest of the system to work (with > > JunitPreferenceInitializer properly defining a value in the preferences), > > would it be better to just play it safe here given that the return value is > > directly passed into StringTokenizer? > > No. We might never have discovered this bug otherwise. Now that the bug has been discovered, presumably a test that mimics the calls and behaviour of JDT's JUnit bundle would be added to prevent this though, no? (In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > I was wondering if a different default value should be passed in as a > > > parameter? While we expect the rest of the system to work (with > > > JunitPreferenceInitializer properly defining a value in the preferences), > > > would it be better to just play it safe here given that the return value is > > > directly passed into StringTokenizer? > > > > No. We might never have discovered this bug otherwise. > > Now that the bug has been discovered, presumably a test that mimics the > calls and behaviour of JDT's JUnit bundle would be added to prevent this > though, no? Sure, I expect that Equinox will add such a test ;-). Is there a work-around? This problem renders the JUnit view unusable for me which I use quite a bit :). (In reply to comment #3) > I was wondering if a different default value should be passed in as a > parameter? While we expect the rest of the system to work (with > JunitPreferenceInitializer properly defining a value in the preferences), > would it be better to just play it safe here given that the return value is > directly passed into StringTokenizer? Yes, this code makes the incorrect assumption that the default preference will always be the same as what was defined in the preference initializer. There are various mechanisms available to override the values set in a preference initializer extension: command line overrides, product level overrides, and even someone directly using API to alter the default scope values. IMO the NPE is legitimate bug to be fixed separately, but admittedly fairly unlikely to occur. (In reply to comment #8) > (In reply to comment #3) > > I was wondering if a different default value should be passed in as a > > parameter? While we expect the rest of the system to work (with > > JunitPreferenceInitializer properly defining a value in the preferences), > > would it be better to just play it safe here given that the return value is > > directly passed into StringTokenizer? > > Yes, this code makes the incorrect assumption that the default preference > will always be the same as what was defined in the preference initializer. > There are various mechanisms available to override the values set in a > preference initializer extension: command line overrides, product level > overrides, and even someone directly using API to alter the default scope > values. IMO the NPE is legitimate bug to be fixed separately, I tend to disagree. Yes, it could be overridden but in that case it would be "" and if someone really calls the API and removes our key then an NPE is an adequate punishment ;-). (In reply to comment #7) > Is there a work-around? This problem renders the JUnit view unusable for me > which I use quite a bit :). Either use M4 or switch to the latest N-build which has the issue fixed: http://download.eclipse.org/eclipse/downloads/drops4/N20130103-2000/ |