Hacker News new | ask | show | jobs
by Seol 3515 days ago
Also, error-prone works in a fundamentally different way to FindBugs: error-prone is a compiler plugin, whereas Findbugs is an after-the-fact static analyser. This means, for example, you can include dependencies on the codebase you're analysing in your findbugs checks, but not in error-prone.

This turns out to be really quite relevant if you're building domain-specific static analysis checks, as opposed to just running standard analyses.
1 comments
needusername 3515 days ago
> error-prone is a compiler plugin

Can you provide more information on how this is achieved? As far as I know there is no official, supported, portable API for Java compilers. The only thing I'm aware of is APT and anything beyond that would require significant rearchitecture of the existing compilers.

link
Seol 3515 days ago
Technically, it's not a compiler plugin - it actually replaces javac by extending JavaCompiler, wrapping it and applying additional verifications without altering the output. Effectively it's introducing its own API for compiler plugins, with those being the checks, very much akin to APT.

See https://github.com/google/error-prone/blob/master/core/src/m... for the entry-point.

I'm very close to getting out of my depth here though :)

link
needusername 3515 days ago
This is not close to a plugin. I don't see why the term plugin is used here. This is misleading people into believing error-prone is using a supported API.

I also don't see how it is "very much akin to APT". APT is an API where the A stands for abstract and the I stands for interface. APT therefore is portable across compilers and supported. error-prone seems to be tied to the current implementation of javac.

It is as if words don't have a meaning anymore, all that matters is how you feel.

I am very reluctant to use such a tool because to me it looks likely that it's going to have similar problems to tools by Google relying on the implementation internal APIs in the past (eg. Android or GAE/J). Supporting new versions of Java is going to require serious amounts of effort and therefore going to be very late if it happens at all.

link
Afty 3514 days ago
The standard annotation processing APIs don't provide enough information to do the analyses we want to do, so we do hook into javac internals.

It does require a lot of effort to keep up with OpenJDK updates, but that's my team's job, and we have to do the work anyway to keep Error Prone running inside Google. We tie Error Prone to a specific version of javac, which matches the one we are currently using inside Google (https://github.com/google/error-prone-javac), so we don't have to support multiple different internal APIs. We are currently using a version of javac 9 from about a year ago, and we're planning a bump to something close to head maybe in Q1.

Eclipse integration would be a pain but would look a lot like what the Checker Framework does.

link
needusername 3514 days ago
This is all fine and good if you're a Google internal user who gets support form your team. Things are a bit different if you're a user from outside of Google.
link
Seol 3515 days ago
The distinction I was trying to make was one between where in the toolchain it lives: error-prone is part of compilation, whereas Findbugs is after-the-fact.

Error-prone is a compiler plugin _mechanism_ - once you have an error-prone compiler, the checks are arguments to the compiler just like APT annotation processors are.

It's built on a standard API - the JavaCompiler mechanism built into the Java SDK - but yes, the code does have further dependencies on com.sun packages. This is a little confusing because why expose the compiler for invocation and extension when extensions have to rely on unsupported code?

So, yes, there are ways where the distinction is important, but they're orthogonal to the point I was trying to make.

link