Plug-in system limitations and internal documentation

[Joseph Darcy]

Hello,

As a side note, through a somewhat indirect and brittle procedure, some 
of the effects of modifying source code can be achieved even with 
standard annotation processing; see this blog entry (with a code sample) 
for details:

     "Properties via Annotation Processing,"
https://blogs.oracle.com/darcy/entry/properties_via_annotation_processing

By design, direct code modification was omitted from annotation processing.

Cheers,

-Joe

On 2/25/2013 11:04 AM, Jonathan Gibbons wrote:
> Daniel,
>
> The plugin system is more flexible than the current annotation system, 
> at the cost of being javac-specific. It supports a somewhat simpler 
> command line interface. It also allows access to the full AST, via the 
> com.sun.source.* API.
>
> javac does not support any public form of AST modification within a 
> running compilation. You can only do code transformations by creating 
> new source code, possibly from new ASTs, and compiling the generated 
> code.
>
> -- Jon
>
>
> On 02/25/2013 09:59 AM, Daniel Parreira wrote:
>> Hello compiler-dev,
>>
>> This might appear to be an unorthodox request, but I have found no 
>> other place to express this doubt about javac internals (openjdk8). I 
>> am currently developing a plugin for javac that will add annotations 
>> for a recent genre of concurrency control that will be the focus of 
>> my Master Thesis. Since I require type annotations, I have turned 
>> myself into openjdk8 as my developing platform since bare-java7 does 
>> not support them.
>>
>> The recent plugin system introduced in java8 (contrasting with the 
>> previous annotation processors) is useful for me in this perspective. 
>> However, as far as I could see, the plugin system public APIs does 
>> not allow :
>> - seeing AST nodes at the method level
>> - modifying the AST, by adding or removing nodes
>>
>> As such, how is this plugin system  different from the previous 
>> annotation processor? As far as I can see, the functionalities 
>> offered are the same. In order to modify the AST/see method level AST 
>> nodes, I had to resort to some well known "hacks", namely the cast of 
>> the public APIs interfaces to the compiler inner classes. (references 
>> : http://scg.unibe.ch/archive/projects/Erni08b.pdf , 
>> http://weblogs.java.net/blog/tball/archive/2006/09/hacking_javac.html)
>>
>> Is this the only way to achieve this? Shouldn't the public API also 
>> supply functionalities for modification? According to the article in 
>> page 55 of the Oracle Java Magazine from February 2013 
>> (http://www.oraclejavamagazine-digital.com/javamagazine/20130102#pg56), 
>> it should be supported. Quoting :
>> "
>> Java 8 will bring a new mechanism that allows you to write plug-ins 
>> for the Java compiler (javac). A compiler plug-in lets you add new 
>> phases to javac without making changes to its code base. New behavior 
>> can be encapsulated in a plug-in and distributed for other people to 
>> use. For example, javac plug-ins could be used to do the following:
>> - Add extra compile-time checks
>> - Add code transformations <------
>> - Perform customized analysis of source code
>> "
>>
>> At last, is there any kind of internal documentation besides the 
>> javadoc in the source files? Information about the internal 
>> functioning of javac in openjdk8 is extremely limited and most of the 
>> information has to be inferred by digging into the JavacParse.java / 
>> TreeMaker.java / JavacCompiler source files. The most difficult 
>> aspect to infer is how to symbol table works and how to actually 
>> create valid AST nodes. I couldn't quite understand how, for example, 
>> a reference to a method is passed into a JCMethodInvokation.
>>
>> Thank you for your time,
>> Daniel Parreira - nº 36780 - CS Bsc - Faculdade de Ciências e 
>> Tecnologias da Universidade Nova de Lisboa, Portugal 
>> (http://www.fct.unl.pt/)
>