Helping to find the usefulness of a proposal

[Jonathan Gibbons]

Mark,

Quick hacks are good.  My point was just that once you know the coding 
pattern, it can be even easier/quicker to hack up an annotation 
processor to do what you want than to learn the innards of the 
compiler.  The internal API has never been intended for public 
consumption, and there are often undocumented quirks or constraints 
about individual specific methods, meaning it is very much a case of 
"proceed at your own risk".  The good news is that is now a goal to 
support utilities such as you all have been describing, and that JSR 
199, JSR 269 and the Tree API, are all part of the formal support for 
such work.

-- Jon




Mark Mahieu wrote:
> Hi Jon,
>
> Invoking the parser directly seemed like the quickest way of grabbing 
> some figures at the time, but you (and Michael) are quite right of course.
>
> The main point I was trying to get across was there are easily 
> approachable ways that people can attempt to do some of the analysis 
> Stephen mentioned, without ripping components out of Netbeans etc to 
> do it, great though they may be.
>
> But I shouldn't be spreading my bad habits around with abandon like 
> that, quick hack or not :)
>
> My apologies.
>
> Mark
>
>
> 2009/4/2 Jonathan Gibbons <Jonathan.Gibbons at sun.com 
> <mailto:Jonathan.Gibbons at sun.com>>
>
>     For all this sort of analysis, you'd do better to use the
>     combination of javac's
>     annotation processing framework and the javac Tree API, than to
>     use direct
>     access into private javac API.
>
>     Annotation processing isn't just for processing annotations ;-)
>      You can write
>     a processor that will be called on all types, and you can bridge
>     from the
>     processing world (javax.lang.model.*) to the java Tree API
>     (com.sun.source.*)
>     using com.sun.source.util.Trees.   This allows you to write
>     utilities to
>     analyze ASTs without requiring the use of any javac internal API.
>
>     -- Jon
>
>
>
>
>     Mark Mahieu wrote:
>
>         Wow.
>
>         http://www.geekherocomic.com/comics-highres/2009-02-25-coding-overkill.png
>
>
>         Here are the important bits from my quick hack.  Took under
>         half an hour to
>         get it finding cases where Auto-assignment Parameters would
>         and wouldn't
>         work across large source trees.
>
>         Of course, javac makes much more than parsing available if you
>         need it...
>
>
>
>         import com.sun.tools.javac.file.JavacFileManager;
>         import com.sun.tools.javac.parser.JavacParser;
>         import com.sun.tools.javac.parser.ParserFactory;
>         import com.sun.tools.javac.tree.TreeScanner;
>         import com.sun.tools.javac.tree.JCTree.JCCompilationUnit;
>         import com.sun.tools.javac.tree.JCTree.JCMethodDecl;
>         import com.sun.tools.javac.tree.JCTree.JCVariableDecl;
>         import com.sun.tools.javac.util.Context;
>         import com.sun.tools.javac.util.List;
>
>         ...
>
>         // create a TreeScanner to do your analysis
>         TreeScanner scanner = new TreeScanner() {
>
>         @Override
>         public void visitMethodDef(JCMethodDecl tree) {
>          // look at a method's parameters
>         for (List<JCVariableDecl> l = params; l.nonEmpty(); l = l.tail) {
>         JCVariableDecl param = l.head;
>          // examine param or whatever
>         }
>          // continue recursively scanning the method body etc
>         super.visitMethodDef(tree);
>         }
>         };
>
>         ...
>
>         Context context = new Context();
>         JavacFileManager.preRegister(context);
>         ParserFactory factory = ParserFactory.instance(context);
>
>         String sourceCode = readSourceFromFile(...);
>
>         JavacParser parser = (JavacParser)
>         factory.newParser(sourceCode, false,
>         false, false);
>         JCCompilationUnit cu = parser.parseCompilationUnit();
>
>         // do your analysis
>         scanner.scan(cu);
>
>          
>
>
>