Earlier quoted context omitted.
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…
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 a…
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.