Guice annotation processor?

[Steven Goldfeder]

Hi everyone,

As a follow up to Christian's post about static analysis using error-prone: would there be interest in adding an annotation processor to Guice so that we can give compile time errors without depending directly on error-prone? With a few exceptions, the errors given by the annotation processor would overlap with the ones that are (or soon will be) in error-prone, but if there's an interest, we can add most of them as an annotation processor in Guice.

If there is an interest, I'd like to complete this in the next few weeks, so feedback is greatly appreciated.

Thanks!

Steven

[Sam Berlin]

The more that can be done by default at compile time with Guice, the better!

Steven

--
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 google-guice...@googlegroups.com.
To post to this group, send email to google...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-guice.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Christian Gruber]

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. That said, I
think the checks we have in mind are, in all cases, within the feature
set of java annotation processing. So I think we're good.

Side note - the error-prone folks have gotten some warmth towards the
idea of integrating the error-prone maven plugin as a part of the
maven-compiler-plugin's underpinnings, so it can just be "yet another
compiler" option, so it is trivial to use.

All in all, it's a good time for java tooling and analysis. :)

Christian.

On 2 Aug 2013, at 12:52, Sam Berlin wrote:

> The more that can be done by default at compile time with Guice, the
> better!
>
>
> On Fri, Aug 2, 2013 at 3:45 PM, Steven Goldfeder
> <sgold...@google.com>wrote:
>
>> Hi everyone,
>>
>> As a follow up to Christian's

>> post<https://groups.google.com/forum/#!topic/google-guice/c8nLliAZ0lQ>

>> about
>> static analysis using error-prone

>> <https://code.google.com/p/error-prone/>:

Christian Gruber :: Google, Inc. :: Java Core Libraries :: Dependency
Injection
email: cgr...@google.com :::: mobile: +1 (646) 807-9839

[Tim Boudreau]

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

[Christian Gruber]

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.

[Tim Boudreau]

On Monday, August 5, 2013 10:19:05 AM UTC-4, Christian Gruber wrote:

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

I noticed that Guice has a design-time phase, and figured sooner or later somebody would use it and discover all the reasons running arbitrary code inside an IDE's VM is a bad idea (the NetBeans team went there and got the t-shirt while I was on it) :-)

Since most Guice modules *do* add up to declarative statements that just happen to be in Java, it's possible to do some limited flow analysis based on it, which is enough to figure out at least some things - just ignoring statements that are likely to be non-trivial to analyze, or which are obviously stateful.  So, you can probably at least discern what types definitely are bound with a high degree of confidence, but not which ones aren't.

I think if you want to do better static analysis, sooner or later, you're going to need a standard for declaring and binding configuration stuff, similar to what the giulius-settings stuff does here - https://github.com/timboudreau/giulius - that is, if a tool can infer the values of bound strings and primitives, you gain the ability to make more assertions about the behavior of the code at runtime.

 

- specifically
run-time code not available to us in the annotation processing APIs.  

Yeah.  Basically, you can do limited flow analysis and track variable assignments, and figure out some subset what the configure() method of a module does.

I *could* actually imagine a tool that loaded Modules into a stubbed out version of Guice that just printed out binding information, and doing it with a SecurityManager that blocks file writes and network i/o - do that in a separate process and parse the output.  Probably overkill, and would fail sometimes, but it would allow richer information than static analysis will ever get - and if you do the SecurityManager stuff right, you can do it without wreaking havoc on the user's system.  Might not be worth it - the point of diminishing returns comes up pretty fast on this sort of thing.  But fun to think about :-)

-Tim