@SuppressFBWarnings retention policy CLASS causes compiler warnings/errors in downstream projects

[nmatt]

@SuppressFBWarnings (in particular) has retention policy CLASS. This causes compilation warnings with javac (when recommended warnings are enabled) if a class file using that annotation is in the class path but the annotation itself is not:

warning: Cannot find annotation method 'value()' in type 'SuppressFBWarnings': class file for edu.umd.cs.findbugs.annotations.SuppressFBWarnings not found

When compiling with -Xlint:all -Werror (which is an often-recommended default), that causes compilation to fail.

The scenario is that the source code of lib1.jar contains @SuppressFBWarnings, and then when a project2 that uses lib1 is compiled, and does not itself has the annotations as a dependency, it is affected by that issue, although the fact that lib1 uses @SuppressFBWarnings ought to be just an implementation detail. Project2 can work around the problem by either including the annotations as a dependency, or by compiling with -Xlint:-classfile, but having to do so is not desirable and only a workaround.

The issue has been raised in the past in a couple of places, e.g.:
https://stackoverflow.com/questions/37422191/
https://mail-archives.apache.org/mod_mbox/freemarker-dev/201604.mbox/%3c506510854.20160416123030@freemail.hu%3e

The problem could be fixed by changing the retention policy for @SuppressFBWarnings from CLASS to SOURCE. This may, of course, be a breaking change for some clients (although I find it difficult to imagine reasonable use cases for that). Maybe an option is to publish an alternative package (e.g. different artifact ID) having retention policy SOURCE for @SuppressFBWarnings, with the caveat that it should only be used as a compile-only dependency (as to not conflict with downstream projects using the current package). One can of course build such a module oneself, but it would be better to have it officially available.

[nmatt]

I now think that I was confused. SpotBugs works on class files of course, so there is no way around using retention policy CLASS for the annotations. It's still unfortunate that one has to use -Xlint:-classfile wholesale, but that is a javac issue.