Community
Participate
Working Groups
Build Identifier: It would be nice for the usage of PMD tokens for this annotation would not be flagged by this check. See this for how PMD defines to use this annotation. http://pmd.sourceforge.net/suppressing.html Reproducible: Always
I'll investigate
I don't think we should open the door here. We operate completely within the spec in java.lang.SuppressWarnings#value(). If PMD wants to use @SuppressWarnings although it is not a complete compiler, then you can just disable this warning in the Eclipse compiler (and maybe offer a replacement in PMD that considers more warning tokes as supported).
I looked at the java spec and did not see the requirement that the values in this annotation were limited to a specific set. In fact it seemed to indicate that the compiler would define its own set. I guess I'm suggesting that an analysis tool like PMD that would utilize the common annotation for developer familiarity would have some level of compiler support, such as the compiler allowing additional string patterns that are not the compilers warning (like "PMD.*") to be used without that being an additional warning. Our actual build compile uses the Sun/Oracle compiler and we do not get these warnings, but we get them in the eclipse environment. To us, they are a false warning that we would like to globally suppress.
We won't make the set of supported warnings globally configurable. The PMD compiler doesn't have to be active for all Java projects in the workspace, so a global option would hide too many unhandled tokens. To stop the JDT compiler from emitting this warning, you can call javaProject.setOption(JavaCore.COMPILER_PB_UNHANDLED_WARNING_TOKEN, JavaCore.IGNORE) on projects where you don't want it. That makes the JDT compiler behave like javac.
Verified for 3.7 M4
