A few thoughts.
We wouldn't be building people's object graph in the IDE, as the
configure() method means that in order to fully extract the object
graph, we would need to do flow analysis on the code - specifically
run-time code not available to us in the annotation processing APIs.
Error-prone has more access to more APIs, and could do more aggressive
flow analysis, but it's tricky, and in the case of Guice models, they
can be conditional, so it would be fairly complicated, and we have a lot
of low-hanging fruit. Over time, we can get more aggressive (with due
respect to performance concerns).
Thanks for the pointer to the JAVAC stuff in maven. I don't know that
we want to do that, but the error-prone folks may well want to.
c.
On 5 Aug 2013, at 1:33, Tim Boudreau wrote:
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.
Christian Gruber :: Google, Inc. :: Java Core Libraries :: Dependency
Injection
email: [email protected] :::: mobile: +1 (646) 807-9839
--
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.
