[JSR308] Checkers - a useability problem, suggestion and idea

[Adam Warski]

Hello,

I my earlier post, I asked if it wouldn't be better if the checkers  
framework used a stand-alone parser (instead of working as an  
annotation processor, plugged into javac), and wouldn't have a  
dependency on Sun's tree API.  Michael provided good answer to these  
questions:
- plugging into javac and using checkers as an annotation processor  
doesn't only give you a parsed source tree, but also symbol resolution  
(implementing it on your own is a lot of work)
- people can use the javac-jsr308 only for static-analysis, and their  
own (not necessarily Sun's) compiler to do the "regular" work of  
compiling classes for distribution

And I agree that the dual-compiler configuration is an acceptable  
solution. What I'm aiming for, is a setup where I use an arbitrary  
java 5 compiler, and javac-jsr308 for static checking. Of course, I  
will have to use type annotations inside comments in all the "new  
places" (like method receiver) defined by jsr308. That's also the only  
way to comfortably work with IDEs so that they don't highligh errors.

There is, however, a problem. While it is OK that my program will have  
a static-analysis-time dependency on Sun's tree API (or even compile- 
time dependency), it can't have a run-time dependency.

But it will: if I use, for example, the @NonNull annotation anywhere  
in my program (not in a comment - let's say on a method parameter),  
then when my annotated class will be loaded, the classloader will have  
to load the NonNull annotation, and then the value of the ImplicitFor  
meta-annotation, which contains a reference to Tree.Kind in Sun's tree  
API. In a non-Sun JDK this may fail.

The solution is, I think, quite simple: the Checkers framework would  
have to provide a copy of the Tree.Kind enumeration. That way, the  
public API would be completely decoupled from the JDK implementation  
(something that is quite desirable, I think), and it could be changed  
in the future to accomodate to a possibly new JDK without problems. A  
simple enum translation class would handle turning Checkers-tree-kind  
to Tree.Kind, in TreeAnnotator's constructor.

Now, the suggestion - wouldn't it be better, if the checkers jar would  
be split in two:
- the public API, containing only the qualifiers (and probably the  
Checkers-tree-kind classes)
- the annotation processor implementation

Then, programs using javac-jsr308 for static analysis, would only have  
to bundle the checkers-api.jar in their distribution.

Finally, the idea - I haven't checked if it's possible yet :). I  
concerns decoupling checkers from the compiler, and making it work as  
a stand-alone library. As I wrote earlier (or rather, Michael), the  
key advantage of plugging into javac is having symbol resolution.  
However, the whole compiler is a jar! So maybe it would be possible to  
bundle it with Checkers and call the parsing and symbol resolution  
outside of javac? There are two things to check here:
- if there aren't any native methods called
- if there wouldn't be any licensing problems.

-- 
Adam