[Checkers] Problems with NonNull checker
mpapi at csail.mit.edu
Mon Apr 21 14:49:01 EDT 2008
> > (Also, it seems like the long delay is caused mainly by checking
> > "FunctionBinary.java", which is ~17k lines. You can use "-Afilenames"
> > to see which files are being checked.)
> That is long, but it doesn't take very long to compile. Is there some
> remaining inefficiency in the checker?
There could very well be. However, I don't expect the NonNull checker
to be as fast as, say, the Interned checker; NonNull calls into the
factory for every member select (compare to Interned, which does so
only for != and ==, and IGJ, which has an empty visitor). NonNull also
uses flow-sensitive inference, and customizes it to do a bit of extra
checking (for "!= null" checks). It does seem like it's slower than it
should be, but not so slow as to be alarming at this point.
> > Deleting the entire "checkers" directory made these errors go away. I
> > haven't tried updating the qualifier definitions -- that might work,
> > though you'd probably have to copy checkers.metaquals as well.
> I think I'm using the latest version of the qualifiers annotations; there
> is no diff between the Daikon and checkers versions of checkers.quals.
> In case it helps, this is the specific error message that I am seeing; I
> only have to change that one instance.
Sorry if I was unclear -- deleting "checkers" only fixed the static
dereference issue for me; the @Raw issue remains. In fact, I tried
replacing @Raw with @NonNull, and I get "cannot find symbol" for
NonNull as well (and for this reason I suspect that it's a compiler
I'm not seeing differences in the qualifiers in Daikon CVS, but
~mernst/tmp/nninfer/invariants-java/checkers/quals has old
definitions. In particular, the declaration is lacking the
@TypeQualifier meta-annotation, which causes the framework to reject
(both implicit and explicit) attempts to add NonNull to a type.
> If we could comment this out or use some other mechanism, then I wouldn't
> have to have a copy of the qualifiers in Daikon. (This is the mechanism
> that Mahmood was asking about recently.)
I started working on this a while back and got sidetracked; I'll see
what state the code is in. Personally, though, I think this is a
slippery slope. Annotations in comments give us backward
compatibility, enabling us to compile code in Java 5/6. Optional
imports have nothing to do with backward compatibility at all, and I
could imagine this confusing users that have legitimately commented
imports (rare as they may be).
More information about the checkers