You can now add an arbitrary number of secondary null annotation types, to be evaluated when reading class files external to the project. Within the configuration dialog, Content Assist is offered based on accessible annotation types, but for secondary annotation types unresolved names will be tolerated. This avoids the need to bloat the build path with transitive compile-time dependencies.

In the dialog that opens, only one primary set of annotations is supported; these are the annotations which JDT actively uses in Quick Fixes, error messages etc. These annotations must be present on the project’s build path.

Please open the dialog for configuring null annotation types from the project properties at Java Compiler > Errors/Warnings > Null analysis :

You can now configure annotation-based null analysis to use multiple sets of annotation types. This is relevant if your project uses 3rd party libraries that already use null annotations in their API, where the annotations used in a library may be different from those used in the current project.

Improved null analysis with generics

The interplay of null annotations and generics has been improved in several regards.

The basic concepts had already been documented in the online help, but not all that was documented was actually checked by null analysis. With the changes outlined below, null analysis based on type annotations is even more capable than previous versions.

(1) The first batch of contributed improvements implements what we call pessimistic analysis for free type variables, which affects implementors of generic types.

In order to allow clients to instantiate such a generic class with either a @NonNull or a @Nullable type as substitution for the "free type variable" <T> , the implementation of that class must account for the worst in both directions:

To anticipate a @NonNull type, each field typed to a free type variable must be initialized with a non- null value, and passing null where T is expected is illegal; and

To anticipate a @Nullable type, each dereference must be preceded by a null check.

At the bottom of each problem hover, you will find a link to the corresponding configuration option, should you like to change the severity of this diagnostic. Note that configurability is mainly given for smooth migration from previous JDT version; conceptually, problems detected by pessimistic analysis should be treated as errors, because they invalidate the null-guarantees given by a generic type.

(2) The second improvement concerns consumption of generic types from a library, more specifically: invocations of library methods whose return type is given by a free type variable.

If the library type is instantiated with a @NonNull type as the type argument, we generally want to interpret the mentioned return type as non- null , too. This is problematic only for some "legacy" methods, which may return null without declaring so. The most prominent example is java.util.Map.get(K) .

The analysis cannot see whether absence of a null annotation for such a return type is intentional (in the above sense of "free type variables"), or an omission that should be fixed. For that reason a new warning has been implemented to alert about this situation.

In the above example, both fields list and map provide @NonNull String as a type argument, hence the return types of both get methods are interpreted as non- null . For List this is desired, for Map it is a bug.

The dilemma can be resolved by adding a (possibly empty) external annotation file ( .eea ) to each affected library class. By using an empty annotation file, the user signals that all types in this class should be interpreted verbatim (like in the List case - use with care). In the other case, the missing @Nullable annotation should be added as an external annotation (like in the Map case).

In a project that is not yet configured to use external annotations for the library in question, the warning is demoted to level "information". Generally, the severity of this problem is configured using the option right below the one mentioned above, titled Unsafe '@NonNull' interpretation of free type variable from library.