JDK-6723459 : javac to flag where warning suppression is not required
  • Type: Enhancement
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 5.0
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2008-07-08
  • Updated: 2019-06-17
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
Relates :  
Description
A DESCRIPTION OF THE REQUEST :
modify the javac compiler so that the standard behavior, or the behavior with an additional qualifier is that when a @SuppressWarnings() annotation is encountered, and the annotation does not suppress any warnings that a warning message may be generated to flag this redundancy

JUSTIFICATION :
if @SuppressWarnings is specified at some time then the reason for the suppression is eliminated, for example due to an underlying API be generified, then the annotation can be removed. There is no easy way to detect this condition, so the annotation stays, and may mask potential issues in the future

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
javac -Xlint unchecked -XWarnOnSupressionNotUsed ...
Warning xxx line 34: unchecked warning suppressed but none are generated
ACTUAL -
no indication

CUSTOMER SUBMITTED WORKAROUND :
try removing each of the @suppressWarnings and see if warnings are generated

Comments
But presumably, we would expect the warnings to be disabled in such "non-standard" scenarios.
29-07-2016

Note there may be some difficulties applying such a flag in the JDK (and other code bases) where certain code is compiled under different JDK versions. For example, @SuppressWarnings("deprecation") Foo would only be relevant if compiled against a JDK version where Foo was deprecated. For example see JDK-8062385.
29-07-2016

This should, presumably, be another -Xlint warning, which would have the side effect of being enabled when -Xlint or -Xlint:all is used.
28-07-2016

Raising priority, because of JEP 277.
28-07-2016

This also related to the warnings work going on in JEP 277 (JDK-8065614), which changes the warnings and suppression behavior specified in the JLS and in javac. As @Deprecated comes into wider use, and deprecations switch to forRemoval=true, this increases the likelihood of stray @SuppressWarnings annotations being left around after code maintenance.
28-07-2016

Jan, I can take a look at this one, if you want.
10-03-2015