This is a set of slides, not a proposed specification. While it
serves to provide intuition, it is informal, incomplete, and retains
quite a bit of ambiguity.
Also, some long-standing problems have not yet been addressed. For
example, the mailing list has discussed the need to separate
* specifying what a value is (e.g., null or non-null)
* specifying whether a particular tool should issue an error (warning
Once you are ready to iron out the details and write up the proposal,
then I'm sure the JSR 305 community and EG are eager to proceed.
Getting experience with some implementations of the JSR 305
annotations will also be helpful in indicating any remaining
shortcomings, and also in building community support.
I'm not saying that the current proposal is bad -- just that it is
incomplete, so the community cannot evaluate its technical merits. I
look forward to the details.
There are lots of different use cases for JSR-305 annotations. A
static analysis tools that tries to identify only the most likely null
pointer defects is different than a tools that tries to prove that
software can't deference a null pointer. Both are useful.
I'm happy to work to try to formalize things more, but I don't want to
specify things to the depth you might expect because I don't want to
specify how static analysis tools use them, only as to their intended
meaning. I'm very interesting in hearing what aspects of the
annotations you think might be ambiguous or ill-defined.
I also want to get more feedback on whether the approach is acceptable
before I spend more time writing up the details.
I'm confused by this statement. How else would you define the meaning
of annotations other than by giving rules that can be used to tell,
for any program, if it is OK, problematic, or plain wrong? (You may
have more or fewer than three points on the scale.) Any tool that
follows a significant proportion of the rules more often than not
would be useful, of course.
We also don't want to specify how a static analysis algorithm would do
things such as determine which paths are feasible.
Thus, we aren't going to specify exact what warnings a static analysis
tool should generate for a particular code fragment.
Instead, I'll be describing what the annotations denote. Given that,
in some cases it will be obviously that the code is bogus and a
warning should be generated. In other cases, the decide isn't so clear