This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 240852 - Improving compile-time support for "null checking" annotations
Summary: Improving compile-time support for "null checking" annotations
Status: NEW
Alias: None
Product: java
Classification: Unclassified
Component: Hints (show other bugs)
Version: 7.4
Hardware: PC All
: P3 normal (vote)
Assignee: Svata Dedic
URL:
Keywords: PATCH_AVAILABLE
Depends on:
Blocks:
 
Reported: 2014-01-22 23:47 UTC by 280Z28
Modified: 2015-11-24 09:16 UTC (History)
1 user (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments
Initial implementation of the described annotation processor (22.37 KB, text/java)
2014-01-22 23:47 UTC, 280Z28
Details

Note You need to log in before you can comment on or make changes to this bug.
Description 280Z28 2014-01-22 23:47:12 UTC
Created attachment 144274 [details]
Initial implementation of the described annotation processor

Currently there is no compile-time validation process associated with the following annotations.

* CheckForNull
* CheckReturnValue
* NonNull
* NullAllowed
* NullUnknown

While much of the useful static validation for these annotations comes from static checkers that are substantially too slow to include in the standard build, another benefit is the information conveyed by including the annotations in the signature of a field, method (return value), or parameter. To that end, there are many validations that can be efficiently performed during the compilation process (using an annotation processor) to ensure that the information conveyed by these annotations is accurate and reliable.

I have developed an annotation processor to accompany these annotations which currently performs the following validations.

Errors
------

* An element in annotated with more than one of [CheckForNull, NonNull, NullAllowed, NullUnknown]
* A method which returns void is annotated with any of these annotations.
* An element with a primitive type is annotated with CheckForNull or NullAllowed.
* A parameter is annotated with NonNull, but the method overrides or implements a method where the same parameter is annotated with NullAllowed or NullUnknown.
* A method is annotated with CheckForNull, but the method overrides or implements a method that is annotated with NonNull.
* A method is annotated with NullUnknown, but the method overrides or implements a method that is annotated with NonNull or CheckForNull.

Warnings
--------

* An element with a primitive type is annotated with NonNull or NullUnknown.
* A parameter is annotated with NonNull, but the method overrides or implements a method where the same parameter is not annotated.
* A method is annotated with CheckForNull, but the method overrides or implements a method that is not annotated.

Note Regarding Variance
-----------------------

The messages described above allow for "covariant" method annotations and "contravariant" parameter annotations. For example, a method annotated with NonNull may override or implement a method annotated with CheckForNull. Also, a parameter may be annotated with NullAllowed when the method overrides or implements a method where the same parameter is annotated with NonNull (such an annotation suggests that the overriding method supports additional argument combinations that the base class or interface does not require).

Note Regarding Future Annotations
---------------------------------

Future releases may include alternative annotations which serve a similar function to the ones handled by this annotation processor. In such a case, a possible upgrade path involves updating this annotation processor to treat semantically equivalent annotations in sets.

Summary
-------

The errors currently reported by this processor do not cover every misuse of these annotations, but they certainly cover some of the biggest. In each case, the error indicates the developer made a serious mistake in communicating information about a section of code.

Incorporating this annotation processor *will break the current build* due to misuses of these annotations that has simply gone unobserved. The owner of this annotation processor will need to work with the owners of broken modules to address annotation misuse before the annotation processor is applied to the entire codebase. Over time, modules may be updated to address the warnings reported by this processor as well.
Comment 1 Svata Dedic 2015-10-02 15:59:09 UTC
Nice idea.
Comment 2 Svata Dedic 2015-11-24 09:16:52 UTC
Hi. The only issue I have with the AP is that there are many many frameworks, which define nullable/non-null metadata. A user is likely to use annotations which are either supported by his application framework (JEE, Spring, ...) or her favourite libraries (apache, checker, pmd, ...). 

The processor declares strict set of annotations; as an alternative, it could declare * as supported annotation and appropriate cmdline options to define what are the individual types of annotations - then getElementsAnnotatedWith can work with proper set of annotation for the project.

Detaching from the umbrella; it's a different thing anyway - if implemented, will require some work in Ant projects, Maven projects and project system UI + harness.