In recent Juno milestones JDT has added several new static analysis capabilities - resource leak detection (Juno M3), annotation based null analysis (Juno M4), null analysis for fields (Juno M5). This week I have been testing these new features on the entire Eclipse SDK source code.
While there are quite a few 'gems', the following code pattern occurs quite frequently. If the object can be null at the first if condition, how is it magically guaranteed to be non-null at the second if statement? :-)
As Stephan mentioned in his blog today - Help the JDT Compiler helping you. Please start using the new static analysis options and report any issues you find. In the process you will certainly make improvements to your code as well.
Nice to see JDT finally getting some of the basics that FindBugs and PMD have had for years. Hopefully it can catch some of the What the F*! moments we see everyday.
ReplyDeleteOne possibility to improve Eclipse quality would be to *enforce* the NPE checking via more strict build settings. I've just created https://bugs.eclipse.org/bugs/show_bug.cgi?id=369901
ReplyDelete*Years* ago I've requested to do this by using FindBugs, but it was rejected (https://bugs.eclipse.org/bugs/show_bug.cgi?id=279212
https://bugs.eclipse.org/bugs/show_bug.cgi?id=247073). Let see if the bug above will be rejected too...
Regards,
Andrey
Not sure what you are writing about. First condition explicitly checks is it null and executes remove() only on not null field. Second condition does not check nullability, so the warning is correct (in context of code you've pasted).
ReplyDelete@Anonymous: Exactly, the warning is correct, and there are several instances of such a warning in Eclipse SDK source.
ReplyDelete