-
Notifications
You must be signed in to change notification settings - Fork 288
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conflict when running Checker Framework and NullAway in the same build #462
Comments
Thanks for the report! This must be related to not shadowing Checker Framework jars anymore, but I am stumped as to what could be happening. Two questions:
|
yes, I could, brix is open source, I just have to roll back to these changes |
Figured this out. TL;DR: running Checker Framework and NullAway together is causing problems. I see this in the output of
The We could temporarily fix this by bumping NullAway's https://github.com/kelloggm/checkerframework-gradle-plugin#incompatibility-with-error-prone @xenoterracide if you have any other thoughts / suggestions let us know. |
Ugh, stop relying on checker framework.... Lol Maybe make like gradle and have an internal version that has transformed package names. No really, that's not a bad idea. I'm not certain how Gradle does this and I'm pretty sure guava has the option too, but it's essentially just a package rename or addition. Like com.uber.nullaway.org.checkerframework... Other than that I've got nothing, I'll have to make a call. It's likely I won't use one or the other, not certain which yet, or I'll have to do what you're suggesting which I've thought about doing for other reasons. |
Yeah, we want to avoid re-packaging and shading third-party deps, so that's not an option right now. And we think that there will be few users that need to run NullAway and Checker Framework simultaneously. I'll put it on the TODO list to do a bump of Checker dataflow, but as noted above I don't think that's a long-term solution. |
I don't have A better solution than those. I'll have to pick one of the 2 options since I'm not going to implement double compilation for every java project I do. |
I also want to mention that checker framework explicitly states that it will break API with any given release, so I think that it may be best simply to say that using with checker framework is not supported somewhere due to this fact. Alternatively, you could provide a BOM and document supported versions. |
Thanks, @xenoterracide. I also contribute to Checker Framework, so let me think more to see if there is a reasonable solution we haven't thought of. |
One thought I've had is that gradle java needs to have a 'compilerPluginClasspath' this would at least allow a version lock and constraint. However I'm not prepared to write that feature request as I don't fully understand plugins |
@xenoterracide the latest here:
Once 1 gets worked out, at least we should be able to discover future incompatibility issues more quickly. Also, in my experience the APIs for the |
Update here: once #485 lands and we cut a new release, there should be no incompatibility between Checker Framework and NullAway anymore |
FYI NullAway 0.9.2 has been released, and that version no longer conflicts with the Checker Framework |
@msridhar curious, did you ever succeed in the whole backwards compatibility thing with how they package their jars? even if they did, I'd guess that it doesn't 100% solve the problem if nullaway were on a significantly different version. I wonder if I should give checker a try again, this problem has kept me away from it, since their attitude was "we aren't using semver and reserve the right to break ABI on any and do every upgrade" |
Hi @xenoterracide at this point, I would expect that there is no issue with running the Checker Framework and NullAway in the same build. NullAway now depends on a shaded dataflow artifact created just for our project; see #485. So there should be no conflict or semver issues, as the two tools can depend on completely different versions of common libraries. (In fact, Error Prone itself also has its own shaded version of the relevant Checker Framework libraries, so there should be no conflict there either.) If you do run into any issues please let us know and we can take a look. |
this is the offending class
this issue does not exist if I switch my version to
0.8.+
instead of just0.+
The text was updated successfully, but these errors were encountered: