[JSR308] Javac Processor API

[Niko Matsakis]

Hello,

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  
definition.

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.


Niko Matsakis