Annotations for nullness: Nonnull/Nullable/CheckForNull

[Bill Pugh]

OK, we discussed this previously, but I want to review where I think
we are
on nullness, and see if everyone agrees.

Because we allow for default annotations, we should also have an
annotation
that exactly the same as having no nullness annotation of any kind,
including
a default one.

But we also need an annotation that says you should definitely worry
about whether or
not this value is null. In general, tools should strive to verify the
existence
of an explicit null test for such a value.

I think we need these two different annotations for values that could
be null.
Insisting that people add explicit null checks everywhere will likely
discourage
use of the tools.

Thus, the names I propose are:

javax.annotation.Nonnull -- value must not be null
javax.annotation.Nullable -- under some unspecified
circumstances, value might be null
javax.annotation.CheckForNull -- code should anticipate that the
value will be null in some situations

Thus, given:

int f(@Nullable Object x) {
return x.hashCode();
}
int g(@CheckForNull Object x) {
return x.hashCode();
}
int h(@Nonnull Object x) {
return x.hashCode();
}

tools should not warn about possible null pointer errors
in h (although they might complain about calls to h that might pass
null).

tools should warn about a null pointer error in g.

Tools that strive for low false positive should not warn about null
pointer
errors in f. However, tools that strive for low true positive might
decide
to warn about null pointer errors in f (whatever they do if there we
no nullness
annotations of any kind).

Comments?

Bill

[John Tang Boyland]

I think this is a good idea: to distinguish the default Java case
from the strict checking case.

John