Eclipse JDT 3.8 Understands Null Annotations
Null pointer exceptions (NPE) are among the most common symptoms of failures in Java programs - a good motivation for developing tools that statically detect potential NPEs before you even run your program. Eclipse JDT has a history of performing local flow analysis to detect this kind of issues, and this analysis has been constantly improved over the years. Yet, this analysis had an inherent limitation: it couldn't see beyond the boundaries of a single method, because whole system analysis is just not feasible for a compiler.
Support for null annotations released with Juno
I'm happy to announce that this limitation has been removed in JDT's 3.8 release (Juno): JDT now understands a small set of null-related annotations, which the user may apply to connect the analysis across method boundaries.
The concept is basically to augment method signatures by annotating which arguments do or don't accept the null value and whether or not null is a legal return value. By this kind of contract the two sides of a method - the caller and the callee - can be analyzed in isolation, without loosing essential information at the method boundary.
This annotation based null analysis has been released as part of the annual release (Juno).
For details please see the documentation. Also the Wiki has some information.
This release is just a first step towards ever better tooling, with further steps already in the pipe line. When you start working with these annotations you'll soon find that the compiler still lacks information in two situations: when reading fields and when interacting with 3rd party libraries. Techniques for adding null annotations to libraries are still in the planning phase, whereas handling of fields is currently in beta state.
Public beta supporting null annotations for fields
Designing a good solution for null analysis of fields is actually a tricky issue, given that changes of a field's value are hard to analyze in object-oriented programs, where aliasing, side-effects and concurrency are pervasive.
An experimental solution exists which we offer for download by early adopters, see the wiki for description and install instructions.
Note, that adopting this solution gives best results if you are willing to make adjustments to your code in order to improve its analyzability. Feedback to this experimental solution should help us to decide what will be JDT's final solution regarding null analysis for fields.
Yet another tool?
You may wonder how this feature relates to similar support by other tools.
- First, we're following the long term goal that the analysis shall eventually be strong enough to literally detect all possible NPEs, i.e., we strive for the ability to certify absence of NPE (modulo the typical "tricks" to by-pass analysis, like reflection).
- Secondly, we invest in paving a migration path where mixtures of annotated and unannotated code exist during the process, and still analysis should give good results. Users should be able to tighten the rules at their own pace, and benefit from null annotations at every stage on this way.
- Lastly, we want this analysis to be tightly integrated in the IDE, to give immediate feedback as you type and most prominently: offering a number of quick fixes that help during the process of improving code quality.
The JDT team is convinced that this is a very powerful tool in the battle against the most embarrassing problem in object-oriented programming. However, please don't expect a magic wand; when adopting null annotations you will find that this transition reveals just how sloppy some software designs are with respect to null values. If responsibility for handling null values follows no clear design, this has to be cleaned up while adding null annotations. We're not promising that this is an easy task - few tasks of software design are actually easy. But with annotation based tool support this task can be performed in a systematic and very effective way.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)