Q & A with the Eclipse Committee

NullPointerException (NPE) is a dominating, omnipresent risk in each and every Java application, and at it's root it is an embarrassingly trivial problem.

Over the years, Eclipse JDT has developed several levels of tool support for statically detecting NPEs at compile time. This tutorial will introduce flow analysis, annotation-based contracts and a null-aware type system as the main tools against NPE.

Additional focus lies on organizational issues facilitating the migration from the risky Java era into an NPE-free software world.

Much of software development is about creating variants of things that have been done in similar ways before. Typical means to create such variants include inheritance / subtyping, extension points and dependency injection. Unfortunately, all of these approaches require that the original author anticipated the required variation points in his/her module, to enable you to create whatever variant comes to your mind. This means, modules intended for reuse tend to be bloated with indirections just in case someone needs to modify something, and still many interesting adaptations are simply not possible due to lack of pre-planning.

Object Teams reverses this situation. Creating unanticipated variants is at the core of this approach. Starting with the Neon release, even a running application can be morphed into a new variant of itself.