• Convert to lambda expression
• Convert to anonymous class creation

Before:

After the Quick Assist (Ctrl+1), the 6 lines are condensed into 1:

• Change body expression to block

  

• Change body block to expression

  

• '->' in a lambda expression

• '::' in a method reference

• '->' in a lambda expression:

• '::' in a method reference:

For arrays:

• Create an enhanced for loop
• Create a for loop using an index

• Create an enhanced for loop
• Create a for loop using an Iterator

• Create a for loop using an index and get(i)

• Configure the position of braces within lambda body:

  

• Configure whitespace before and after the arrow operator of lambda:

  

Formatter profiles can be configured on the Java > Code Style > Formatter preference page.

This feature requires a set of nullness annotations declared with @Target({TYPE_USE}), which JDT ships as version 2.0.0 of the org.eclipse.jdt.annotation bundle.

With these annotations, nullness can be considered as an intrinsic part of the type system, allowing the compiler to perform null type checking along with each task of type checking. This is a major step towards systematically detecting all possible NullPointerExceptions in a program.

The most obvious benefit is in annotating type arguments of generic types:

The example shows diverse usage of null-annotated type arguments. While most of the code has been checked to be safe, the compiler directly points out one obvious bug: in is declared with a nullable type, and hence cannot be passed into add() of a list of nonnull elements.

In this variant an error is detected by recognizing that string has been extracted from a list that may contain nulls, hence passing this value into a Predicate expecting a nonnull argument is wrong.

For a comprehensive description of type annotation based null analysis see the online help.

While potentially, the new approach could lead to an explosion of the number of annotations, also @NonNullByDefault has become much more powerful, such that programs not using any null values can be fully checked with just a single annotation:

The @NonNullByDefault annotation in line 7 affects most types in the example (with the exception of local variables, which are inferred using flow analysis). The compiler directly points out the single bug in the safe_ methods: the type argument of list result defaults to '@NonNull String', hence passing null to its add() method is now wrong.

In line 27 all null-defaults are canceled for the scope of method unprotectedClient(). Here we simulate the interface between un-annotated (legacy) code and code governed by @NonNullByDefault. We can observe that all arguments and local variables from the legacy code require unchecked conversions when being passed into the annotated code. In particular note that myStrings lacks two annotations required by the method safeFilter(): the List should be nonnull, and so should be its type argument.

Main points to observe:

Project configuration

No matter if you are adopting null type annotations or continue to use old-style null annotations: always refer to the org.eclipse.jdt.annotation bundle using a suitable version range, either [1.1.0,2.0.0) for declaration annotations or [2.0.0,3.0.0) for type annotations. This is important, because Eclipse now ships with both versions of the annotation bundle.
As an alternative, OSGi/plug-in projects may use a target definition for explicitly selecting the appropriate version of the annotation bundle.

Syntax changes

When migrating to null type annotations, your code may need to be changed if you have null annotations attached to an array type or to a qualified type reference. The latter may simply create a new compile error, while the former implicitly changes its meaning.

Information in the man file can be read by the command "man <path_to_ecj.1>" in command prompt mode.

This option can be configured by clicking the hyperlink next to Search > Java Search > Limit To > Match locations:

• Evaluating expressions and variables from the context of interface methods
• Java Application can now be executed from the static main method in interface (without public modifier also)
• Breakpoints can be added inside lambda expressions

For more information see the bugzilla entry.