The Object Teams Blog

Adding team spirit to your objects.

Bye, bye, NPE

with 5 comments

As I announced earlier most of my time for the JDT currently goes into static analysis, more specifically into analyzing various issues relating to null references.

Since the compiler can’t read our minds on whether we intend to allow null for a method parameter, a method return etc. we should give it a little help: annotate types in method signatures with either @Nullable or @NonNull, thus creating a contract between a method and its callers.

With such contracts it is possible to write code that is provably free of NPEs — wouldn’t that be great?

Let null contracts become mainstream

The theory and some tools for checking null contracts have been around for a while. I think it is time that the Eclipse Java compiler will make this feature directly available within your favorite IDE.

Towards this goal work in bug 186342 has made good progress, but some issues still need discussing and experimenting before this feature can be released into the JDT.

First prototype available

The current prototype is available for download — see these steps for installing into a fresh Eclipse SDK 3.7 M5.

What the prototype supports:

  • @NonNull and @Nullable annotations for method parameters, method return and local variables, seemlessly integrated with the existing flow analysis of the JDT compiler.
  • Inheritance of null contracts with the option of compatible refinement in subtypes.
  • Configuration of a global default (either @NonNull or @Nullable) to reduce the number or required annotations.
  • Configuration of specific qualified names for these annotation types to support compatibility with (some) other tools
  • A few quickfixes for adding obviously missing annotations.

If you like to play with these existing features you’re highly welcome to install the plugin and give feedback in the bug.

If you want to see the full story you may want to wait for some more items from my agenda:

  • Null annotations for fields
  • Nullity profiles for libraries
  • Configurability of the default annotation per package and per type.
  • More quickfixes

Behind the scenes

There’s a second piece of good news in this development: before this feature gets approved for committing into JDT head, I was faced with the usual choice to either evolve the feature outside CVS or create a branch. Since I didn’t like the efforts incurred by either approach – regarding maintenance as well as deployment – I chose the third option: Object Teams.

I transformed my recent patch from the bug into a regular OT/Equinox plug-in. The Object Teams based solution not only avoids the double maintance associated with branching but also makes the specific code for this feature much easier to read because it is localized in exactly one module. Also, the plug-in can be easier comsumed because it can be packaged and deployed independently of the concurrent evolution of the JDT.

By the way: those interested in these and other cool things that can be done with Object Teams: don’t miss our EclipseCon tutorial:

Hands-on introduction to Object Teams

See you at

Written by Stephan Herrmann

February 2, 2011 at 00:02

Posted in Eclipse, Object Teams

Tagged with ,

5 Responses

Subscribe to comments with RSS.

  1. […] Bye, bye, NPE at The Object Teams Blog – view page – cached Everthing Object Teams – adding team spirit to your objects. Show influential only (1) $(‘#filter-infonly’).change(function() { var el = $(this); var url = document.location.href; var checked = el.attr(‘checked’); if (checked) { document.location.href = url + ((/?/.test(url)) ? ‘&’ : ‘?’) + ‘infonly=1’; } else { document.location.href = url.replace(/[?&]?infonly=1/,”); } }); […]

  2. How does your proposal compare to ESC/Java2 ?

    Isaac Gouy

    March 24, 2011 at 17:27

  3. IntelliJ does the same thing. Hopefully you can make it so the specific annotations are configurable so annotations can be shared between IntelliJ and Eclipse. IntelliJ also supports placing annotations externally in XML configuration files so that IntelliJ users can annotate code bases without adding IntelliJ-specific annotations to code that other IDEs are working on. You might want to consider supporting similar functionality.

    Ted Wise

    March 25, 2011 at 16:09

  4. @Isaac: This work on the JDT does not aim at introducing yet another set of annotations and just yet another tool for checking these. Instead I’m trying to leverage the experience from previous tools and wrap it up in a consensual way. In particular, Patrice Chalin, author of the JML4 tool, actively participates in the discussion in As such, the new support in the JDT will essentially be equivalent to any JML-based null checkers.

    The main benefits of putting all this into the JDT are: immediate feedback (reporting as you type) and (eventually) availability in Eclipse without the need to install any additional tools.

    Actually, the design described in isn’t finalized, and if you have particular questions/comments feel free to join in on the mentioned bug.


    March 29, 2011 at 20:10

  5. @Ted: sorry I didn’t see your comment among a backlog of spam comments.

    Re configurability: yes, that’s already implemented as of, see also

    Re external specification files: we’re discussing this in Would you have a pointer for documentation of the XML schema used by IntelliJ?


    April 14, 2011 at 19:32

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: