Contributing a quick fix and a quick assist for Java code

JDT offers a large number of quick fixes and quick assists for Java code. However, you may want to implement your own as well, and it is actually quite easy to do so with the help of org.eclipse.jdt.ui.quickFixProcessors and org.eclipse.jdt.ui.quickAssistProcessors extension points.

Using the extension points
To create a new extension for the extension points you need to first provide the required extensions in the plugin.xml. For example, JDT defines the following processors

 <extension
       point="org.eclipse.jdt.ui.quickFixProcessors">
    <quickFixProcessor
          name="%defaultQuickFixProcessor"
          class="org.eclipse.jdt.internal.ui.text.correction.QuickFixProcessor"
          id="org.eclipse.jdt.ui.text.correction.QuickFixProcessor">
    </quickFixProcessor>
 </extension>
   
 <extension
       point="org.eclipse.jdt.ui.quickAssistProcessors">
    <quickAssistProcessor
          name="%defaultQuickAssistProcessor"
          class="org.eclipse.jdt.internal.ui.text.correction.QuickAssistProcessor"
          id="org.eclipse.jdt.ui.text.correction.QuickAssistProcessor">
    </quickAssistProcessor>
 </extension>

For a description of the individual attributes, please refer to the extension point documentation.

Contributing a quick fix and a quick assist
To contribute a quick fix, you need to create the class that implements the org.eclipse.jdt.ui.text.java.IQuickFixProcessor interface. This is the same class that you specified in the extension declaration. Each Java problem has a unique id which is defined in org.eclipse.jdt.core.compiler.IProblem interface. For a particular Java problem you may offer one or more correction proposals.

To contribute a quick assist, you need to create the class that implements the org.eclipse.jdt.ui.text.java.IQuickAssistProcessor interface. Again, this is the same class that you specified in the extension declaration.

Supplying the right IJavaCompletionProposal
JDT provides the following default implementations for correction proposals that can be used to contribute quick fixes and quick assists.

• org.eclipse.jdt.ui.text.java.correction.ChangeCorrectionProposal
• org.eclipse.jdt.ui.text.java.correction.CUCorrectionProposal
• org.eclipse.jdt.ui.text.java.correction.ASTRewriteCorrectionProposal

Typically you will use an org.eclipse.jdt.core.dom.rewrite.ASTRewrite, in that case you should create an ASTRewriteCorrectionProposal. However, if as a result of a quick assist you want to start an action e.g. open a wizard, you should create a ChangeCorrectionProposal and override its apply(IDocument) method.

Note: These default implementations became API only in 3.8/4.2 (Juno) M6.

Manipulating Java code via ASTRewrite
Using ASTRewrite is simple enough, you can read more about AST and ASTRewrite in this Eclipse Corner Article and in this EclipseCon tutorial (slides 44-46). However, sometimes you may not know which AST nodes need to be modified and to what. ASTView plugin helps you visualize the AST of a Java source file, and is really helpful in identifying what modifications need to be done in the AST.

JDT 3.8/4.2 M6 - New and Noteworthy

M6 was a long milestone - there was one extra week of development - and hence we could do a little bit more.  There are quite a few new features and a few API additions as well.

JDT always provided extension points to contribute Quick Fixes/Assists. However, it was hard for contributors to supply the right IJavaCompletionProposal required by IQuickFixProcessor and IQuickAssistProcessor interfaces. This has been improved as JDT now provides the following default implementations for correction proposals

• org.eclipse.jdt.ui.text.java.correction.ChangeCorrectionProposal
• org.eclipse.jdt.ui.text.java.correction.CUCorrectionProposal
• org.eclipse.jdt.ui.text.java.correction.ASTRewriteCorrectionProposal

This makes it easier to implement quick fixes/assists that operate on .java files and use an ASTRewrite. Of course you could always use the internal implementations, but then your code would be littered with forbidden access warnings and the implementations could change any time :)

The bracket matching support in Java Editor has been improved, and among other things it now supports highlighting of enclosing brackets.

This can be configured on the Java > Editor preference page.

While the feature is visible in Java editor, the infrastructure is in Platform/Text. Hence, if anyone wishes to add the same functionality to other editors they can make use of the following types

• org.eclipse.jface.text.source.DefaultCharacterPairMatcher
• org.eclipse.jface.text.source.MatchingCharacterPainter

Marcel Bruch, of Code Recommenders fame, added the concept of sorting to the content assist framework by adding several new APIs on the content assistant and the processor - see org.eclipse.jface.text.contentassist.ICompletionProposalSorter. Thanks Marcel, and hope to see more contributions from you in future! :-)

There are a few more interesting items, like Selectively ignore errors/warnings from source folders and
Null analysis treats org.eclipse.core.runtime.Assert like Java assert. You can read the complete list here.

As always, feedback is greatly appreciated especially in the form of bug reports!

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!