[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