JSR-305 status: I'm ready; is the JSR-305 community ready?

342 views
Skip to first unread message

Bill Pugh

unread,
Jul 15, 2008, 7:09:01 PM7/15/08
to jsr...@googlegroups.com
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. 

We haven't added anything for TypeQualifierValidator yet.

I've also added the JCIP concurrency annotations to javax.annotations.concurrent

We should shortly be adding support in FindBugs for proposed JSR-305 annotations about whether resources passed as parameters to methods should be closed (@WillClose, @WillNotClose, @WillCloseWhenClosed).

----

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.

At the moment, I'm fairly happy with what is described in 


I need to hear more feedback as to whether the expert group and the JSR-305 community is happen with that.

I'm not sure if the TypeQualifierValidator idea should make the cut; I'd appreciate some feedback on that.

Bill






Michael Ernst

unread,
Jul 16, 2008, 12:53:25 AM7/16/08
to jsr...@googlegroups.com
> At the moment, I'm fairly happy with what is described in
> 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

unread,
Jul 22, 2008, 1:58:45 PM7/22/08
to jsr...@googlegroups.com
I don't think JSR-305 should specify how tools should use the
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

unread,
Jul 23, 2008, 3:25:48 AM7/23/08
to jsr...@googlegroups.com
On Tue, Jul 22, 2008 at 6:58 PM, Bill Pugh <pu...@cs.umd.edu> wrote:
> 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

unread,
Jul 23, 2008, 7:54:33 PM7/23/08
to jsr...@googlegroups.com
Some people want to use static analysis to prove that their program
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

unread,
Jul 28, 2008, 11:11:49 AM7/28/08
to JSR-305: Annotations for Software Defect Detection
On Jul 16, 1:09 am, Bill Pugh <p...@cs.umd.edu> wrote:
> 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.
>

Good.

> I've also added the JCIP concurrency annotations to  
> javax.annotations.concurrent
>

Great.

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.

Besides the above statet addition, I think everthing so far in JSR-305
quite useful and complete, meaning I am happy so far.

Have fun,
Marcus
Reply all
Reply to author
Forward
0 new messages