Improving Java code quality with Eclipse Juno

The Eclipse Java compiler performs more checks and analyses than are mandated by the Java Language Specification. See Java > Compiler > Errors/Warnings preference page for available options.

Now several of these options should be obvious, however a few maybe not :-) In Juno we (I mean Stephan) added a few pages to give some background on certain analyses and hints on how to make the best use of them.

Please let us know if these pages could be improved, or if you want to know more details on some other compiler options as well.

Weird code pattern in Eclipse SDK

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.

Annotation based null analysis with JDT

Eclipse Juno M4 includes support for annotation based null analysis. To take advantage of the feature enable the preference shown below and start using the default annotations mentioned in the text fields.

You will also notice that all the null analysis related options have moved to a new group on the preference page.

As usual feedback is extremely welcome especially in form of bug reports :-)

UPDATE: JDT provides default annotations which are shipped in org.eclipse.jdt.annotation bundle with the Eclipse SDK. However you are free to use your own annotation types, just specify the custom annotations in the preferences.

Detecting resource leaks with Eclipse JDT

You can now detect resource leaks with Eclipse JDT. The following 3 warnings have been added, and the defaults are as shown (this feature is available in I-Builds starting Oct 4 )

For the purpose of this analysis, a resource is a local variable of type java.io.Closeable in pre-Java 7 world and in Java 7 world a resource is a local variable of type java.lang.AutoCloseable. (Note that in Java 7 java.io.Closeable extends java.lang.AutoCloseable)

To take a few examples

• if close() is never called on the resource a 'Resource is never closed' warning is emitted

• if close() is called but not on all code paths, the warning indicates the locations where the resource is not closed

•  if a locally created resource is passed to another method, then it cannot be ascertained what that method does with the resource, i.e. the method may or may not close the resource, e.g. in the snippet below a helper method is used to close a resource, however one may also create helper methods to perform other tasks. Hence, in these cases the warning is a 'Potential resource leak' and this warning is not enabled by default.

•  if a resource is correctly closed, and the compiler compliance is 1.7 then Eclipse suggests to use the new try-with-resource statement

Several other cases are also handled, e.g. a resource is returned from a method, a resource variable is reassigned etc. However, we may have missed something, hence bugs, suggestions and comments are welcome!

Most of the credit for this feature goes to Stephan Herrmann, in fact I often wonder how he gets time to contribute so much to JDT given that he has a day job and is also the lead of the Eclipse Object Teams Project. Thanks Stephan!