Intro. @Nullable / @NonNull (and @NonNullByDefault) "type" annotations 59/47359/2
authorMichael Vorburger <vorburger@redhat.com>
Thu, 1 Sep 2016 20:32:20 +0000 (22:32 +0200)
committerStephen Kitt <skitt@redhat.com>
Mon, 31 Oct 2016 13:03:35 +0000 (13:03 +0000)
These are "better" than those in package javax.annotation from FindBugs
(JSR-305), because they are (newer) @Target({ TYPE_USE } annotations,
which can annotate more places than similar older annotations.

FYI: I'll start to use these annotations in some work I'm doing, and
annotate some ODL code with these - just because they are more flexible
than FindBugs' annotations.

FTR: This is *NOT* a jab at FindBugs - I love FindBugs and will strongly
support its introduction in OpenDaylight; as I have for Checkstyle.
FindBugs does a lot of interesting and useful static code analysis in
addition to null analysis, all of which will add value to code quality
in ODL.  I just happen to think that specifically for null analysis, not
other checks, FindBugs is not the best game in town (anymore); and both
Eclipse and probably IntelliJ's (which I know very little about) are
superior (now); and e.g. https://sourceforge.net/p/findbugs/bugs/1355/
seems to confirm this.

Please note that the fact that this has "org.eclipse.jdt" in its name
does *NOT* in any way tie this (only) to "Eclipse" as in the IDE per se!
Eclipse does indeed now have native built-in support for static null
analysis (which BTW FYI can also be run on the command line, outside of
the IDE...), but putting these annotations on code does NOT "tie" ODL in
any way to Eclipse ... these are JUST annotations, which presumably
(hopefully) e.g. IntelliJ is flexible enough to be configured to use as
well (an IntelliJ user should ideally test and confirm this).  They are
just better, more modern, versions of this kind of annotations than are
available elsewhere (we could even define our own in ODL; but why would
we).

There is no strong technical need for us to exclusively use only these
annotations in ODL; at least Eclipse' null analysis supports several
types (and so does IntelliJ presumably; FYI in Eclipse, one type has to
be designated the "primary", but AFAIK it can be configured for interop.
compatibility with code annotated with the other, older,
javax.annotation @Nullable / @NonNull from FindBugs (JSR-305) as well).

This is a very small new JAR with only 4 annotations in it related to
static code analysis for null-ability.  Its declared <scope>provided, so
it can be used at compilation time, but doesn't end up in the shipped
product.

Change-Id: Ie60241a3b7b0845496d3af8393db2661720f5394
Signed-off-by: Michael Vorburger <vorburger@redhat.com>
odlparent/pom.xml

index 6dd4d224f735d01f10ad6b39a078588759d7dfee..93d30eb3d0626c782b61c4a99567fb1ad9875e20 100644 (file)
           </exclusion>
         </exclusions>
       </dependency>
+      <dependency>
+        <groupId>org.eclipse.jdt</groupId>
+        <artifactId>org.eclipse.jdt.annotation</artifactId>
+        <version>2.0.0</version>
+        <scope>provided</scope>
+      </dependency>
       <dependency>
         <groupId>com.google.code.gson</groupId>
         <artifactId>gson</artifactId>
       <artifactId>jsr305</artifactId>
       <scope>provided</scope>
     </dependency>
+    <dependency>
+      <groupId>org.eclipse.jdt</groupId>
+      <artifactId>org.eclipse.jdt.annotation</artifactId>
+      <scope>provided</scope>
+    </dependency>
   </dependencies>
 
   <build>