[JSR308] Re: Annotation processing (JSR 269) and AST representation

Eugene Kuleshov eu at javatx.org
Sat Feb 3 14:05:32 EST 2007


  The class file change is needed to allow non-Java languages to 
preserve same information in unified way. If annotations for parallelism 
recently described by Doug Lea recently are expressed in the bytecode, 
non-Java compiler can produce those annotations and allow to reuse the 
same bytecode-level annotation processor to parallelize execution.

  This would of course require additional constraints on javac compiler 
(as well as on other on-Java compilers). Such constraints would specify 
how source level artifacts should be mapped to the bytecode, but I don't 
think 1-1 mapping is an absolute requirement for this. For example there 
is no requirement for it to be reversible. However it should allow the 
data flow and code flow analysis similar to what AST processors can do, 
but not necessary the exact equivalent.

  Anyways, this is not new to the relation between Java source and the 
bytecode, for example try/catch and synchronized blocks are presented 
very differently in the class file and even vary between different 

  It also worth to mention that there is no "official" API for working 
with the class files and everybody using class file format chapter of 
the JVM specification as a replacement for such API.

  I hope that we can find an acceptable solution to this after Java 
language and AST ussues are sorted out.


Neal Gafter wrote:
> OK, but none of those require changes to the class file. What API 
> changes do we want that would require class file format changes?
> On 2/3/07, *Michael Ernst* <mernst at csail.mit.edu 
> <mailto:mernst at csail.mit.edu>> wrote:
>     > I believe we need to look at
>     > com.sun.source.tree and related APIs, and think about how we
>     want to extend
>     > them in parallel with the language.
>     Yes.  The current proposal says:
>       The JSR-269 annotation processing API must be modified so that
>     the process
>       method (currently invoked only on class, field, and method
>     annotations) is
>       also invoked on annotations on typecasts, receivers, type
>     arguments, and
>       local variables. Additionally, the Tree API, which exposes the AST
>       (including annotations) to authors of compile-time plug-ins, must be
>       updated to reflect the modifications made to the internal AST
>     node classes
>       described in section 3.
>     We have implemented all these changes in the JSR 308 reference
>     compiler,
>     which we plan to release in February.  That implementation will give a
>     starting point for discussions and improvements.
>                         -Mike

More information about the JSR308 mailing list