[JSR308] Checkers - a useability problem, suggestion and idea
adam at warski.org
Fri Oct 10 04:04:41 EDT 2008
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
- 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
- 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.
More information about the JSR308