JSR-305 status: I'm ready; is the JSR-305 community ready?
Bill Pugh
Michael Ernst
> http://www.cs.umd.edu/~pugh/JSR-305.pdf
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
suppression).
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.
-Mike
Bill Pugh
annotations, or give examples of which code snippets should generate
warnings.
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.
Bill
Radu Grigore
> 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 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.
--
regards,
radu
http://rgrig.blogspot.com/
Bill Pugh
can't dereference a null pointer. Other people want to use it to find
the null pointer bugs that are most likely to represent serious bugs.
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
cut.
Bill
Marcus
> OK, we now have pretty much full implementation of my proposed JSR-305
> type qualifiers in FindBugs. Dave Hovemeyer has finished up a number
> of extensions to the earlier work. We have regular, exclusive and
> exhaustive type qualifiers, and some basic interprocedural analysis of
> type qualifiers.
>
> I've also added the JCIP concurrency annotations to
> javax.annotations.concurrent
>
I was just wondering whether there is an annotation with a stronger
contract than @Immutable to define statelessness of an object. I mean
something that means no mutable fields at all. Is this still in the
scope of JSR-305?
>
> So what I need is feedback as to whether or not we are approaching a
> draft set of annotations, or whether we are far from agreement on what
> we will do with JSR-305 or whether JSR-305 will even happen.
quite useful and complete, meaning I am happy so far.
Have fun,
Marcus