JDK-6299893 : Allow SuppressWarnings to be specified at the package level
  • Type: Enhancement
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: linux
  • CPU: x86
  • Submitted: 2005-07-21
  • Updated: 2010-04-02
  • Resolved: 2005-07-21
Related Reports
Relates :  
Description
A DESCRIPTION OF THE REQUEST :
I have a lot of generated code from javacc in my project, that one compiled produces hundreds of warnings.  This is infuriating because I have little to no control of the code that is generated and cannot remove the warnings.  It would be nice if the SuppressWarnings annotation could be applied to the package specified in the package-info.java file.  SuppressWarnings can be applied to pretty much everything else except for packages, so I feel this is an omission.

Example contents of package-info.java:

@SuppressWarnings("all")
package some.package.with.lots.of.warnings;

JUSTIFICATION :
It would mean I can differenciate warnings in my own code from warnings in generated code much easier.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
SuppressWarnings should work exactly like it does when used elsewhere except that the scope of the warning supression should be the entire package.
ACTUAL -
As it stands, SuppressWarnings cannot be applied to a package and the compile will fail.

---------- BEGIN SOURCE ----------


Contents of package-info.java:

@SuppressWarnings("all")
package some.package.i.have.no.control.over.that.generates.loads.of.warnings;


Currently this code will not compile, as there is no target that allows the annotation to be applied to a package.
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
There is no workaround.
###@###.### 2005-07-21 09:41:35 GMT

Comments
EVALUATION In response to SDN comments: We are monitoring the comments for new information and should such information arrive, we would certainly revisit this issue. However, the current evaluation is that the suggested change comes with a cost. Furthermore, we have suggested two different ways to work around the problem.
06-06-2006

WORK AROUND 1. compile the generated code by itself using -source 1.4 and -target 5. 2. request an updated version of javacc which either uses suppresswarnings or doesn't generate code which causes warnings. ###@###.### 2005-07-21 23:37:35 GMT
21-07-2005

EVALUATION The warnings actually indicates potential problems in the generated code. Currently, SuppressWarnings have the desirable property of only affecting lexically nested code. This means that you can immediately see if a warning might be suppressed in code you're reading. This proposal would violate this property to solve an uncommon problem which in most cases can be worked around. ###@###.### 2005-07-21 23:29:16 GMT
21-07-2005