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.

Active JDT Committers

In my talks on JDT I generally include a slide with the above image. I thought I should also write a post and include the following bits of (interesting) information about the committers.

• JDT committers are spread over 3 continents, 4 countries and 5 cities.
• More than half (6 out of 11) of active committers are based out of Bangalore, India.
• Dani and Olivier have been there since the very beginning of Eclipse, and Markus has been a JDT committer since 2003.
• Srikanth has been working on compilers and related technology forever.
• In all eight to nine languages can be spoken in the team. Even the commiters in Bangalore speak many different languages, for instance I can communicate in my mother tongue, Hindi, only with Ayush. Hence, we pretty much communicate in English :-)
• Unfortunately the team is dominated by men with Raksha being the only member of the fairer sex.
• Ayush at 24 is the youngest committer in the team and I come a close second at 25. 

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.

CodingSpectator: Research study on Eclipse

These guys have been contributing to JDT by reporting a bunch of bugs based on their findings, so I thought I should talk about them :)

The aim of CodingSpectator project is to study how developers interact with the Eclipse IDE, by collecting and analyzing usage data. CodingSpectator has been developed at Ralph Johnson’s research group by the following graduate students: Mohsen Vakilian, Nicholas Chen, Stas Negara, Roshanak Zilouchian and Balaji Ambresh. Ralph is a co-author of the seminal book on design patterns (GoF) and his research group has a history of important contributions to IDEs. CodingSpectator monitors programming interactions non-intrusively in the background and periodically uploads it to a secure server at UIUC.

They have presented some of their findings in this technical report - Use, Disuse, and Misuse of Automated Refactorings. Based on the same report they have reported a number of insightful bugs against JDT and also provided suggestions on how some of the refactorings can be improved. A few bugs have already been fixed. In addition their technical report also improved my understanding of an average JDT user's behavior. Thanks guys! 

Probably the biggest challenge with a usage study is finding a good number of participants. They are looking for more participants in order to continue their research study. If you’re interested in helping the researchers out, you could install CodingSpectator. 

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!

Java 7 Support in Eclipse 3.7.1, 3.8, 4.2 builds

So far the Java 7 support work was done in the BETA_JAVA7 branch. This branch has now been merged to HEAD and R3_7_maintenance. As a result all upcoming 3.7.1, 3.8 and 4.2 builds will fully support Java 7 development.

Java 7 Support in Eclipse JDT (BETA) - Part III

I have already talked about adding Java 7 support to your Eclipse 3.7 or 4.1 install. Last week I also talked about the new features in JDT for Multi-catch, try-with-resources and Simplified Varargs Method Invocation. Now I will talk about Improved Type Inference for Generic Instance Creation (Diamond).

This language change allows explicit type arguments to constructors of parameterized classes to be omitted in many situations. The compiler infers the omitted type arguments based on the expected type.

The JDT compiler detects redundant specification of type arguments, which you can remove via Remove type arguments quick fix.

 

 This warning can be configured as shown below.

 
 You can also insert inferred type arguments via a quick assist.

Where possible, Content assist inserts diamond instead of explicit type arguments.

Future items: We plan to show the inferred type arguments right in the constructor hover, see bug 351048. In 3.8 we also plan to provide Remove redundant type arguments as a cleanup, see bug 351956.

Note that the type inference done by the compiler can at times be non-obvious. For example, at first glance the following two methods might appear equivalent, when in fact the one with conditional operator has an error.

An analogous example from the pre-Java 7 world.