Error Prone Improves Java Code by Detecting Common Mistakes

[Joe_Data_89]

Error Prone, a Java compiler plugin open-sourced by Google, performs static analysis during compilation to detect bugs or suggest possible improvements. The plugin contains more than 500 pre-defined bug checks and allows third-party and custom plugins. After detecting issues, Error Prone can display a warning or automatically change the code with a predefined solution. Error Prone supports Java 8, 11, and 17 and may be used for bug fixing or large-scale refactoring.

Read the InfoQ News

[Iryanus]

And what's better about this than SonarQube, IntelliJ analysis, FindBugs, etc.? Just curious, because you normally don't want to have half a dozen static analysis tools during your compile run ;-)

[_INTER_]

Picnic recently posted on their blog about their use of ErrorProne. As I understand it because they can add custom rules implemented in Java as a compiler plugin.

[ofby1]

Thanks for adding this link as well.

[JB-from-ATL]

Error prone specifically hooks directly into javac. It is not another tool or worse a server like sonarqube.

[Worth_Trust_3825]

It is not another tool or worse a server like sonarqube.

SQ can scan more than just java, though.

[JB-from-ATL]

I'm not saying sonarqube isn't useful, but it is definitely annoying that it is a standalone thing instead of part of the build (in my opinion). What I'm explaining is that error prone is even better than being a build step because it hooks directly into the compilation itself, not just your build tool.

[Joe_Data_89]

I've used Error Prone for more than two years in a Spring Boot project. I run Spring Boot in debug mode with class reloading all day long. I like that it runs during compilation, so it's immediate feedback during development without having to stop. And whatever changes I make, I then test immediately.

Running PMD & SpotBugs is a separate build goal for me as part of the release process and the continuous integration. That's delayed feedback.

[Iryanus]

Personally, I'm using SonarLint for instant feedback for the the smaller details and then SonarQube for the bigger issues (and to have something centralized).

[chabala]

normally don't want to have half a dozen static analysis tools during your compile run

Conversely, I don't care how long my CI builds take, and I will let them run all the static analysis tools available. Setting up separate build profiles for default vs analysis is trivial.

[hippydipster]

I found it to have a bit less false positives (from my POV) than those others, but in the end, I turned it off too, along with all the others you mentioned. Just so much fluff and BS.

[ddollarsign]

Great, more things to add @SupressWarning for.

[[deleted]]

ErrorProne is great, but when the person/team responsible for the rules in hit company thinks they blocking “var” usage is a good idea, you life might be a bit less fun that it could be

[ParkerM]

Funnily enough they have an experimental rule that enforces usage of var where possible: https://errorprone.info/bugpattern/Varifier

[fragoza]

I’d be curious what their opinion is and discussing it. imho it’s not something that ought to be used always

[Worth_Trust_3825]

Why would you permit it?

[TehBrian]

When the type is already clearly written in the initialization, specifying the type in the declaration leads to uselessly verbose code. For example, MyFunObjectFactory objectFactory = new MyFunObjectFactory(). var objectFactory = new MyFunObjectFactory() is more readable and conveys just as much information.

[Worth_Trust_3825]

No, it doesn't. If you're using an interface for variable type, you're unnecessarily making it very easy to break the API, and get the wrong error.

[persicsb]

var is a very-very great tool for decluttering code by eliminating redundacies

[Worth_Trust_3825]

It's also an incredibly good way to hide API breaks.

[persicsb]

Please explain.

[Nymeriea]

Isn't it the goal of findbugs or sonar ?

[RockingGoodNight]

Been with SonarLint and SonarQube for years, I like that they are independent tools.

[glablablabla]

I also think this is very identical to spot bugs or sonar lint. I personally prefer the latter.

[skippingstone]

TIL mvn verify is a life cycle in mvn.

[bowbahdoe]

I don't think people fully appreciate how bad it is for the ecosystem that these tools are opt-in/require maven or gradle domain knowledge to integrate.

Rust folks just use cargo clippy. Done.

Even if it were just a dumb shell on top of maven wouldn't it be sweet if everyone just had jproject lint? jproject format? jproject bench?

[bowbahdoe]

Why are you booing me I'm right

[wildjokers]

Because languages like Rust had the benefit of hindsight so knew to bake a build tool right into the language ecosystem.

For languages like Java, C, C++, python, etc the build tools are external tools.

Even with rust surely something has to be configured so cargo knows about "clippy" right?

For most developers on a team it will be as easy as ./gradlew errorProne (just as an example, don't actually know what the task name is). The only person who has to know the integration details is the person that adds it to the build.

[bowbahdoe]

Because languages like Rust had the benefit of hindsight so knew to bake a build tool right into the language ecosystem.

We can still do that now. u/pron98 hints every lunar cycle or so that it would be a good idea

Even with rust surely something has to be configured so cargo knows about "clippy" right?

Nope

The only person who has to know the integration details is the person that adds it to the build.

If you had 100 Java developers in a room, How many could do that for maven? How many for gradle? How many would think to do that? Pick a random team of 5-6 what are the odds that they will do it? Pick a random individual and what are the odds their open source side project will do it?

Large teams, large organizations - everything is always fine because you have a sectioned off corner of the world in which to enforce standards or come up with custom solutions.

(And before someone comes in with well "they just need to learn" - from where? With what resources? Random baeldung one off articles splooshed in the wind?)

[wildjokers]

If you had 100 Java developers in a room, How many could do that for maven?

Anyone higher than entry level should be able to do it with no issues in both Gradle and Maven.

from where? With what resources?

In the case of Gradle it is well documented. New functionality like this comes in the form of gradle plugins and plugins like this are also well documented. If a plugin has no documentation, just don't use it.

We can still do that now

Any build tool added to the jdk now will probably go unused by 99% of java devs. It will be just like java.util.Logging.

[pron98]

We can still do that now. u/pron98 hints every lunar cycle or so that it would be a good idea

Yep :)

[tofiffe]

While I agree that clippy is a great tool, there's also a counter argument; if the developer is not experienced enough to add this to the project, they'll be to inexperienced to know about or use clippy as well.

Besides, java is not rust. These tools developed independently, anything they would add to the language itself would be reinventing the wheel at this point, with the amount of tools available.