RFE: configurable DoNotCall/RestrictedApi/JdkObsolete/DefaultCharset/JavaTimeDefaultTimeZone check

[tbroyer]

Description of the problem / feature request:

I'm currently using Policeman's Forbidden API Checker in addition to Error Prone. Some checks are duplicate of what Error Prone provides (default charset, default timezone), but Forbidden APIs provides additional checks (e.g. APIs using the default locale, no System.out/System.err or printStackTrace()), and allows one to add new checks through simple text files.

It occurred to me that those checks could be done at compile-time by Error Prone itself.

Feature requests: what underlying problem are you trying to solve with this feature?

Remove a tool that duplicates (some) functionality of Error Prone and runs later during the build (also contributing to build time); bringing its features to Error Prone itself:

• more checks: default locale, no System.out/System.err, or printStackTrace()
• configurable "forbidden APIs" checks (à la DoNotCall, RestrictedAPI, JdkObsolete, DefaultCharset, or JavaTimeDefaultTimeZone) through simple text files (rather than writing dedicated Error Prone checks). Alternatively, make it dead-easy to build such checks (possibly using protobuf to store the forbidden signatures, à la ApiDiff).

I might try to build those as custom checks (if I find time), but thought you might be interested in adding this right into Error Prone itself.

What version of Error Prone are you using?

2.3.2

[Stephan202]

W.r.t. point 2 (making it configurable): that could then also trivially replace modernizer-maven-plugin. (I started working on an Error Prone replacement for this plugin a while back, but didn't yet bring it to a production-ready state. If there is wider interest in this I can see about finalizing and open-sourcing it one of these weeks.)

[cushon]

configurable "forbidden APIs" checks (à la DoNotCall, RestrictedAPI, JdkObsolete, DefaultCharset, or JavaTimeDefaultTimeZone) through simple text files (rather than writing dedicated Error Prone checks)

One way we've discussed approach this is having a mechanism for associating annotations with APIs that we can't annotated directly (e.g. JDK APIs), similar to what the Checker Framework does with stub files. Then we wouldn't need e.g. both CheckReturnValue (which handles the annotation) and ReturnValueIgnored (which has the hard-coded list of JDK APIs), we could just add stubs with @CRV for JDK APIs and the CheckReturnValue bugpattern would handle both cases.

We don't have concrete plans around that, but I hope it happens someday.

Doing something more targeted with flags or config files for the specific checks where this is most annoying might be a more pragmatic short-term fix.