78

What is the best 'NonNull' annotation?

"Best" in the sense of

  • Standard way e.g. future proofness (e.g. support by standard jdk etc.)
  • Support of IDE's (shows up in java doc to indicate the usage for developers)
  • Support by static analysis tools like findbugs
  • Support for runtime analysis

Here's how the world currently look like - any further insight is appreciated:

  • javax.validation.constraints.NotNull (Docs)
    + javax package thus seems futureproof
    - Part of JEE not JSE. In JSE need to import additional libs.
    - Not supported by static analysis tools (runtime validation only)

  • edu.umd.cs.findbugs.annotations.NonNull (docs)
    - external library and not an javax package
    - deprecated since findbugs version 3.X
    + used for static analysis (by findbugs and therefore Sonar)

  • javax.annotation.Nonnull (docs)
    + used for static analysis (in findbugs)
    - JSR-305 is dormant/dead/unknown as on the fb mailing list indicated. The author Bill Pugh, even if directly asked, hasn't commented the state in years...

  • org.eclipse.jdt.annotation_2.0.0 (docs, interesting presentation)
    + used for static analysis (in eclipse not in findbugs though)
    - proprietary to eclipse (didn't try to use them standalone)

  • org.jetbrains.annotations.NotNull (docs)
    + used for static analysis (in intelliJ not in findbugs though)
    - proprietary to IntelliJ (but also publicly available as a jar)

  • lombok.NonNull(docs)
    + used to control code generation
    - proprietary annotation

  • android.support.annotation.NonNull (docs)
    + static analysis in android studio
    - android specific proprietary annotation

  • org.checkerframework.checker.nullness.qual.NonNull (docs)
    + JSR308 implementation which is part of Java8 (which did introduce the ability to write annotations in different parts of your code, but did not introduce new annotations)
    + used for static code (not findbugs though) and runtime analysis
    - external lib however seems to be endorsed by the java folks

Currently I would tend to the Checker Framework but I am looking forward for other views...

[disclaimer] I know the question has been asked here however was not answered (or the answer was wrong/incomplete/outdated) [/disclaimer]

Community
  • 1
  • 1
Lonzak
  • 9,334
  • 5
  • 57
  • 88
  • 11
    I would appreciate if you "vote to close" comment on your reasons. I took time to write this question and would appreciate if you also spend some time! – Lonzak Mar 09 '16 at 12:57
  • One of these links: [manual](http://types.cs.washington.edu/checker-framework/current/checker-framework-manual.html#nullness-checker), [Javadoc](http://types.cs.washington.edu/checker-framework/current/api/org/checkerframework/checker/nullness/qual/NonNull.html) would be better than the given link for the Checker Framework version. – mernst Mar 09 '16 at 15:57
  • Your link is to the Javadoc for the annotation processor, instead of to the Javadoc for the annotation itself. I think a link to the manual is more appropriate; the Javadoc for the processor contains no information. – mernst Mar 09 '16 at 16:07
  • 5
    Very similar question here: http://stackoverflow.com/q/4963300/873282 – koppor Mar 31 '17 at 14:58
  • Yes I knew that link already (as writen in the question) but as you may have seen it dates back to 2011 which was over 6 years ago. Things have changed since then. – Lonzak Apr 05 '17 at 19:46
  • 19
    Nominated to reopen because the asker has defined "best" objectively. – Kevin Krumwiede May 10 '17 at 21:59
  • @KevinKrumwiede what's the biggest difference to the similar question mentioned in the comments? and how the current question can be answered, first of all, without a primarily opinion-based input? – Farside Aug 24 '17 at 10:42
  • I think is gaining more traction especially with interop between Kotlin and Java. That is at least why I searched for it and voted to reopen. There is discussion in https://github.com/Kotlin/KEEP/issues/79 around how the Kotlin compiler should treat Java annotated code, so answer to this question would be very useful. – mkobit Oct 17 '17 at 21:07
  • Your comment is a duplicate of koppor's comment (and the disclaimer in the post) – Lonzak Dec 11 '18 at 11:35
  • 1
    @Lonzak You should have _improved_ the original question instead of _duplicating_ it. Now someone looking for an answer or wanting to (improve the) answer does not know where to do so, which question is the authoritative / best, and has to do extra work. This is not good, and that's why I asked the moderators to merge both questions. – ax. Dec 20 '18 at 13:10

1 Answers1

28

There is no standard @NonNull annotation. Creating such an annotation was the goal of JSR 305, which has been abandoned for a long time. There will not be a standard @NonNull annotation until JSR 305 is reconstituted. Oracle has no current plans to do so. (JEE annotations are outside the scope of JSR 305.)

For futureproofing, the most important factor to consider is whether the annotation is a type annotation or a declaration annotation. Because @NonNull states a property of the variable's value rather than of the variable itself, it should be a type annotation. Being a type annotation also lets the annotation be written on more locations, as in List<@NonNull String>.

You can determine whether an annotation is a type annotation by looking at the @Target meta-annotation on the annotation's definition. As of this writing, it seems that only the Checker Framework and Eclipse versions are type annotations, so I would choose them over the ones that are declaration annotations. Note that the developers of any of the other annotations could update them to be type annotations as well; I don't know of their plans.

The only downside is that using a type annotation requires use of a Java 8 compiler. The Checker Framework has mechanisms for letting code containing its annotations be compiled by a Java 7 compiler.

mernst
  • 7,437
  • 30
  • 45