NullAway depends on Guava #119
Comments
|
Before looking in detail, at a high level NullAway's dependence on Guava should only affect the annotation processor path, not the build path for your application. So something is up with the config here. Lemme dig a bit more |
|
To double-check: have you actually confirmed with a sample project that the above configuration makes Guava available on the classpath for application code? |
|
There is a bug here. I had assumed that running with Error Prone meant that Guava would just be available to annotation processors. Looks like on Bazel, EP manages to hide its version of Guava from annotation processors. So we should make our dependence explicit, I guess. |
|
You're right; this doesn't affect the app classpath. When I add a I agree that an explicit dependency would be better than an implicit one, but I am a little suspicious about the interaction between EP's Guava and NullAway's Guava. (What if those version don't match up?) I feel that it would be safer to avoid Guava altogether in a low-level utility like this, but I suppose that's just a feeling rather than a high-priority bug. I'll rename this bug from "NullAway depends on Guava, which can conflict with my app's version of Guava" to "NullAway depends on Guava" |
dfabulich
changed the title
|
Fair point. I hadn't worried about the Guava dependence since I assumed Error Prone exposed it anyway. (With the EP Gradle plugin it is exposed to annotation processors.) I think a short-term solution is to at least make the dependence explicit to make life easier for Bazel users. Long term, we can think about either removing the dependence or, if that's too painful, distributing a shaded version of Guava with NullAway. BTW, thanks for kicking the tires with Bazel integration! Once we add the explicit Guava dependence and cut a new release, I'll add directions to our wiki. |
|
Thanks, @dfabulich! I was able to set nulaway on Bazel, on this test repo, with diff: I'm, getting: @msridhar +1 to add the integration to the WIKI. While this works, the disadvantage of this approach is that the plugin must be provided per |
|
@davido isn't there a way to register other annotation processors globally in Bazel, like Dagger? I'd be surprised if there isn't some scripting support so you don't have to do this all manually. In Buck we script nullaway configuration across modules via the |
|
@msridhar Not that I'm aware of. https://docs.bazel.build/versions/master/be/java.html#java_library.exported_plugins Can you share how you do it with Buck? Last time we used Buck we had to do monkey patching, and overwrite https://github.com/GerritCodeReview/gerrit/blob/stable-2.13/tools/default.defs#L27-L45 I migrated the build tool in gerrit code review from Buck to Bazel one year ago: |
See #119. Error Prone does not expose its packaged Guava on Bazel. NullAway does indeed rely on Guava, and this will make it work better out of the box on Bazel. Eventually, we can think about shading or getting rid of this dependence, but this is a first step.
We use a combination of Gradle build configuration and OkBuck to inject the NullAway dependence everywhere. And we also do some monkey patching in DEFS to tweak Error Prone configuration (via JVM args) on a per-module basis. |
|
@dfabulich I've updated the docs with your Bazel example; thanks for that! We dug through our code, and our dependence on Guava is fairly deep (e.g., for the caching libraries). So, unfortunately, we are going to have to keep the dependence for the foreseeable future. Going to close this issue, though if we see a way to remove the Guava dependence in the future we'll look into it. |
It was a bit tricky to figure out how to configure NullAway to work with Bazel, though I did ultimately get it to work. https://github.com/dfabulich/bazel-checker-framework-bug/
Unfortunately, I was forced to add a dependency on Guava 22 in my Bazel WORKSPACE, and add it as a dependency of my NullAway
java_plugin.WORKSPACE:
BUILD:
If I comment out the
@guava//jarline, I get aClassNotFoundException, included below.I think that this problem is happening because
NullAway.javadirectly depends on a bunch ofcom.google.commonclasses.I'm a big fan of Guava in general, but this seems like a problem;
it forces my app to take on a compile-time dependency on Guava 22. If my app needs to use a different version of Guava, they'll conflict.I think it would be better if NullAway eliminated its dependency on Guava classes, and used the standard library's utilities instead.error message with stacktrace
The text was updated successfully, but these errors were encountered: