Why Can't I SuppressWarnings on a Package?

Question

I see from the javadoc that the @SuppressWarnings annotation applies to

TYPE,FIELD,METHOD,PARAMETER,CONSTRUCTOR,LOCAL_VARIABLE

targets. Why does it not also apply to PACKAGE?

I have some generated code which contains some raw types warnings. I'd like to be able to add a package-info.java file for the generated classes (in a separate physical directory but the same java package) which tells eclipse to ignore any raw types warnings emanating from the generated classes in package.

Why is this not supported? Is there an alternate way of suppressing a warning in an entire package?

is your problem same with [it](http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6299893) — Farid Movsumov, Jan 18 '12 at 13:25
check [it](http://stackoverflow.com/questions/1127920/how-to-suppress-java-warnings-for-specific-directories-or-files-such-as-generate) please — Farid Movsumov, Jan 18 '12 at 13:26
@faridmovsumov - I am having the same issue as that Oracle "bug". Will have to add my 2 cents to that bug report when I can lookup my Oracle ID. — Tom Tresansky, Jan 18 '12 at 13:49
@faridmovsumov - The SO post you mention is related, but not identical. Thanks for the link! — Tom Tresansky, Jan 18 '12 at 13:53

score 10 · Accepted Answer · answered Jan 18 '12 at 13:36

The reason that suppressing warnings at the package level is not allowed was explained in the response to an old bug report (Status - Closed, Will Not Fix): Allow SuppressWarnings to be specified at the package level.

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.

There are a couple of work arounds suggested in that response as well.

compile the generated code by itself using -source 1.4 and -target 5.

request an updated version of javacc which either uses suppresswarnings or doesn't generate code which causes warnings.

I think the first suggestion, putting the generated code in its own project, should work for you. The second suggestion looks like its more specific to the problem in the bug report. I don't know if you're using javacc or not.

Seems like this is a more common problem than Oracle is willing to admit, based on the number of comments to that bug. Compiling to target version 1.5 is NOT a workaround if you want to use 1.6 or 1.7 features... Unfortunately extracting code to a separate project is not a viable solution for me in this case. — Tom Tresansky, Jan 18 '12 at 14:08
This is depressing. Especially given the rise of static code analysis and the use of SuppressWarnings to narrow the focus of the scans. On large monolithic projects with no political will to refactor generated code, moving projects or generating code in the build is not usually an option. — John Mercier, Oct 04 '17 at 19:05

score 1 · Answer 2 · answered Jan 18 '12 at 13:34

1

Good question. Probably this will be fixed by Oracle in future.

But now I can suggest you the following. Put all generated code to separate project. BTW it is common practice. Then configure this project to be patient to warnings. For example in eclipse you can open project properties/Java Compiler/ Errors/Warings, select "enable project specific settings" and disable all warnings.

answered Jan 18 '12 at 13:34

AlexR

114,158
16
130
208

I don't think extracting the generated code to a separate project is a viable solution in this case. Thanks for the suggestion, though. – Tom Tresansky Jan 18 '12 at 14:04
6

"Probably this will be fixed by Oracle in the future" made me laugh out loud. Thanks for that. – uckelman Feb 22 '14 at 22:16

Why Can't I SuppressWarnings on a Package?

2 Answers2

Linked