[JSR308] Javac Processor API
niko at alum.mit.edu
Thu Mar 1 11:16:37 EST 2007
It may be better to wait to pose this question until the reference
implementation is available, but I am wondering whether JSR308 is
considering any change in the scheduling of Annotation Processors
within Javac. In the official document, it seems that no major
changes are planned to the A.P. interface.
As I understand the javac code --- and my understanding may well be
limited --- compilation currently takes place in four "main" stages:
Parsing, Annotation Processing, Attribution, Flow Checking. These
stages are then followed by desugaring and code generation.
My concern is that if annotation processors using the Tree API
attempt to check the additional type annotations, they will run
before any attribution of the parse trees is done. As a result,
these processors have no access to higher-level semantic information
(in fact, there are no accessors for this kind of information in the
Tree API). For example, if they see an expression like "foo.bar",
they do not know whether foo is a local variable or a field, or what
the type of "bar" is. It seems that even the most rudimentary type
systems will require the ability to trace a field reference to its
While it would be possible for every AP to duplicate this same logic,
it would only be an invitation to bugs. It would be far superior to
allow certain annotation processors to run later on fully attributed
(or even flow-checked) trees.
I can see a couple of concerns right away, but I'm sure there are more:
* Annotation Processors today can create new classes which need to be
processed in turn. If annotation processing were added after the
attribution phase, then there would need to be a way for the
annotation phase to restart to process these newly created classes.
Alternatively, annotations could run at both times, and perhaps would
only be permitted to create new classes in the first phase.
* The Tree API would need to be expanded to include symbol
information. This would make it harder to change javac in the
future. However, given the amount of information already exposed by
the Tree API, it seems that any additional dependencies would be
minimal. Note that the symbols and types are exposed via the
javax.lang.* APIs, so all that is required is for the Tree API to
allow access to that information.
* A.P.s would have greater opportunity to undermine the correctness
of javac. I suppose this is probably true, but seems to me like a
non-issue because the user elects explicitly to include an A.P. in
his workflow. Certainly they are no more dangerous than the current
Java Instrumentation API!
Along those lines, another similar problem is that the Java Messager
API, used to report warnings etc, currently does not accept Tree
arguments as a location, and so can only report problems at a method
resolution, rather than at a precise line. This seems non-ideal, but
perhaps I missed a part of the Trees API that provides an alternate
error reporting mechanism. It can be hard to collect the entire set
of Javac APIs into one's head at one time.
Thanks for your time and thoughts.
More information about the JSR308