Build with javac-with-errorprone #2484
Assignees
Labels
Comments
|
Hi, Can I take up this task? If I understand correctly error-prone is like static checking tool and we include it as part of the maven compiler plugin as shown https://errorprone.info/docs/installation |
|
We wouldn't mind a PR for this, though ideally someday we'll move to Bazel and get it for free :) |
|
This would also be a nice opportunity to enable NullAway: NullAway's nullness checking should be largely redundant with what we have internally, but:
|
copybara-service bot
pushed a commit
that referenced
this issue
Aug 4, 2022
Fixes #2484 RELNOTES=n/a PiperOrigin-RevId: 465133131
copybara-service bot
pushed a commit
that referenced
this issue
Aug 4, 2022
Fixes #2484 RELNOTES=n/a PiperOrigin-RevId: 465133131
Closed
copybara-service bot
pushed a commit
that referenced
this issue
Oct 27, 2022
…nd make builds work with newer JDKs. This should fix the error reported in #6217 (comment). I'm not sure if the Error Prone update was necessary for that or if only the `pom.xml` changes were. Still, it seems inevitable that we'll be forced to upgrade Error Prone eventually, and it's rarely a bad idea to update a plugin. This change is progress toward building and testing under Java 17 (#5801)... ...which we apparently regressed at when we enabled Error Prone (#2484). I've set this change up in a way that lets builds continue to work under JDK8 (which is potentially useful for #3990 or for anyone building Guava manually with an old JDK), albeit with Error Prone disabled. RELNOTES=n/a PiperOrigin-RevId: 484299394
copybara-service bot
pushed a commit
that referenced
this issue
Nov 3, 2022
This has some effects on us as we develop Guava, but it doesn't affect end users. Specifically: - When we build Guava with JDK8, we now have to disable Error Prone. (Again, users can still use Guava with JDK8, including with Error Prone. The effect is limited to people who are developing Guava.) - We can now successfully build Guava with Error Prone under more recent JDKs. That is, this change should fix the error reported in #6217 (comment). (I'm not sure if the Error Prone update was necessary for that or if only the other `pom.xml` changes were. Still, it seems inevitable that we'll be forced to upgrade Error Prone eventually, and it's rarely a bad idea to update a plugin.) This change is progress toward building and testing under Java 17 (#5801)... ...which we apparently regressed at when we enabled Error Prone (#2484). Oddly, it seems that part of our existing Error Prone setup is _required_ to continue building Guava under JDK8. (Such builds are potentially useful for #3990 or for anyone building Guava manually with an old JDK.) That's the case even though we're now disabling Error Prone for those builds. Again, all these changes affect only people who are developing Guava, not end users. RELNOTES=n/a PiperOrigin-RevId: 484299394
copybara-service bot
pushed a commit
that referenced
this issue
Nov 3, 2022
This has some effects on us as we develop Guava, but it doesn't affect end users. Specifically: - When we build Guava with JDK8, we now have to disable Error Prone. (Again, users can still use Guava with JDK8, including with Error Prone. The effect is limited to people who are developing Guava.) - We can now successfully build Guava with Error Prone under more recent JDKs. That is, this change should fix the error reported in #6217 (comment). (I'm not sure if the Error Prone update was necessary for that or if only the other `pom.xml` changes were. Still, it seems inevitable that we'll be forced to upgrade Error Prone eventually, and it's rarely a bad idea to update a plugin.) This change is progress toward building and testing under Java 17 (#5801)... ...which we apparently regressed at when we enabled Error Prone (#2484). Oddly, it seems that part of our existing Error Prone setup is _required_ to continue building Guava under JDK8. (Such builds are potentially useful for #3990 or for anyone building Guava manually with an old JDK.) That's the case even though we're now disabling Error Prone for those builds. Again, all these changes affect only people who are developing Guava, not end users. RELNOTES=n/a PiperOrigin-RevId: 485770768
copybara-service bot
pushed a commit
that referenced
this issue
Dec 13, 2022
…ss` annotations. I would assume we're still not 100% consistent in using them, and we might someday consider an Error Prone check to identify the remaining places that we ought to be using them. But in an ideal world, they'll be able to go away entirely before we need to bother. (There are a few reasons to use these annotations, but the one that I was poking at today was trying to [run NullAway](#2484 (comment)).) RELNOTES=n/a PiperOrigin-RevId: 494743544
copybara-service bot
pushed a commit
that referenced
this issue
Dec 13, 2022
…ss` annotations. I would assume we're still not 100% consistent in using them, and we might someday consider an Error Prone check to identify the remaining places that we ought to be using them. But in an ideal world, they'll be able to go away entirely before we need to bother. (There are a few reasons to use these annotations, but the one that I was poking at today was trying to [run NullAway](#2484 (comment)).) RELNOTES=n/a PiperOrigin-RevId: 494880081
copybara-service bot
pushed a commit
that referenced
this issue
Dec 22, 2022
(followup to cl/494880081) We might _still_ not be 100% consistent in using them. (Again, this helps slightly in my periodic attempts to [run NullAway](#2484 (comment)).) RELNOTES=n/a PiperOrigin-RevId: 497199314
copybara-service bot
pushed a commit
that referenced
this issue
Dec 22, 2022
(followup to cl/494880081) We might _still_ not be 100% consistent in using them. (Again, this helps slightly in my periodic attempts to [run NullAway](#2484 (comment)).) RELNOTES=n/a PiperOrigin-RevId: 497207876
|
Some notes on the impact on build performance: #7093 (comment) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We use it internally. It would be nice for external contributors if we extended that to our open-source build. And it would set a good example. Possibly we could even turn on some compile errors that haven't been enabled for all of Google. Further, this may make it easier for us to switch from Animal Sniffer to the (currently internal but maybe to be released someday?) Error Prone version checker.
The text was updated successfully, but these errors were encountered: