null related annotations

Charles Crouch ccrouch at redhat.com
Tue Jul 10 13:29:00 UTC 2012


Mike T's mention of @NonNull annotations this morning reminded me I'd done some research on this recently, so I thought I would send out my notes. Lets start the discussion/flamefest...


Basically I'm a big fan of anything that can help us catch NPEs at compile time rather than runtime, so I think if we can agree on an approach, we should adopt it and embrace it.

One of the issues folks have had historically is that RHQ has generally used Intellij's annotations but with nothing setup in the main mvn build to check these annotations, the only people to get any benefit from them were intellij users. Well now there are now *lots* of alternatives to intellij's:

http://stackoverflow.com/questions/4963300/which-notnull-java-annotation-should-i-use

e.g. eclipse, findbugs, jsr305, istack (from sun), javax.validation all offer their own set of annotations. We shouldn't use istack apparently: http://stackoverflow.com/a/4963565 and the javax.validation are only meant for runtime not compile time checking.

Unfortunately there is still no standardized set of annotations around handling nulls. JSR305 isn't going anywhere apparently and JSR308 won't land until jdk8 (http://stackoverflow.com/questions/1476757/jsr305-vs-jsr308-java-type-anotations-which-is-going-to-be-the-standard)

Even more painfully there doesn't even seem to be consistency in the names of the annotations across implementations:

For things whose value can't ever be null:
@NonNull(eclipse, findbugs), @Nonnull(jsr305), @NotNull(intellij)

For things whose value can be null:
@CheckForNull(findbugs, jsr305), @Nullable(intellij, eclipse)

For things whose value if it is null, it may be fine or maybe a problem???
@Nullable(findbugs, jsr305)
[IMHO this is pointless and better just to not put any annotation]
http://findbugs.sourceforge.net/manual/annotations.html



So what can we do? Well here are the options I can think of, please add more...

1) We could keep using the intellij annotations and combine that with running findbugs as part of the main build to enforce them.
Findbugs actually has support for converting intellij annotations into one's it knows about:
http://code.google.com/searchframe#Fccnll6ERQ0/trunk/findbugs/src/java/edu/umd/cs/findbugs/ba/NullnessAnnotation.java

2) We could define our own annotations and combine that with running findbugs as part of the main build to enforce them.
The only restriction is we have to use the same Classnames as findbugs, see link above, e.g. org.rhq.NonNull and org.rhq.CheckForNull

3) Or we could use the checker tool, which seems like it is going to be the RI for jsr308: http://types.cs.washington.edu/checker-framework/current/checkers-manual.html
This seems by far the sophisticated and flexible solution: "Your goal is to add @Nullable annotations to the types of any variables that can be null. (The default is to assume that a variable is non-null unless it has a @Nullable annotation.) Then, you will run the Nullness Checker."
The downside with this option is that it seems to want to replace javac, with its own updated version that supports jsr308. "Eventually, you will be able to use any Java compiler, such as the OpenJDK compiler, but Oracle has been slow to incorporate all the patches, so the bundled javac is superior, for the purpose of pluggable type-checking, and is equivalent in all other respects." It's not clear to me how this would work for people just checking out RHQ or in the product build environment.

4)...


More information about the rhq-devel mailing list