On Friday, August 2, 2013 6:46:19 PM UTC-4, Christian Gruber wrote: > Awesome. The upside is users would likely get these analyses by having > guice.jar in their class path. The downside is that java annotation > processing can't do quite as detailed an analysis of things as can > error-prone, which uses javac internals and AST stuff.
I've written annotation processors which use javac internals before - and generally, you can do a *lot* of closure analysis without directly using classes from the JAR containing the annotation class (though it's often easier to be lazy and do it that way). It's a compile-time, not runtime dependency for the processor, so nobody has to ship it (there are versions of javac available via maven, such as this one - http://bits.netbeans.org/trunk/maven-snapshot/org/netbeans/external/nb-javac-api/SNAPSHOT/ ). And you can always put the annotation processor in a separate JAR, so anyone who has issues with the dependency on javac can just not use it. I would admonish anyone attempting this to remember that your annotation processors will also be run inside the VM of people's IDEs, so building gargantuan object graphs or executing a lot of code that may have side-effects is poor form. But you'd be surprised how much tracing through source you can do via javac's api without needing to execute runtime code at all (which is the one way to guarantee not getting nasty surprises). The API is not for the faint of heart, but if you encapsulate the things you repeatedly do in some utility classes, it's manageable - and getting error indications in your editor for free is a lovely thing. -Tim -- You received this message because you are subscribed to the Google Groups "google-guice" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/google-guice. For more options, visit https://groups.google.com/groups/opt_out.
