[Checkers] Nullness checker
Mahmood Ali
mahmood at MIT.EDU
Sun Mar 22 23:54:00 EDT 2009
Greetings,
> thinking about it a bit more, I guess I can answer myself that the
> AnnotationValueVisitor should declare the type as @Nullable.
>
AnnotationValueVisitor needs to be declared as:
interface AnnotationValueVisitor<R extends @Nullable Object, P extends
@Nullable Object> { ... }
> Doesn't that prohibit type parameters that allow null values at all?
> After all, @Nullable Object doesn't extend @NonNull Object, it's the
> other way round. And why do you write this at all, if the default
> qualifier is @NonNull? Doesn't this apply also to type parameters? I
> could be of course missing some obvious variance argument on why this
> is correct ;)
> (another by the way: Map.get should accept a @Nullable parameter)
True. There are two things here:
1. We decided to insert the @NonNull annotation to explicitly state
and emphasize the annotation, despite it being the default.
Especially here, in the case of the Collection API, figuring out the
parameter bound doesn't seem so obvious. For the reason mentioned
below.
2. The Collection API offers optional specification that allow the
subclasses of the interface to be more strict that the interface
itself (e.g. Map.get() and Map.put() optionally may throw
NullPointerException if any of the arguments is a null). It is only
some classes that actually accept null (e.g. the most popular ones,
like ArrayList, LinkedList, and HashMap), but a lot of other ones
don't permit nulls (sorted queues PriorityQueue, Hashtable, most
concurrent collections). We decided to have the interfaces be as
strict as possible (i.e. marked with @NonNull) and have the concrete
implementations permit Nullable elements (check declaration of
ArrayList).
Hopefully that answered your question. I will clarify the comment on
jdk skeleton files.
- Mahmood
More information about the checkers
mailing list