...
According to the Java API, Annotation Type SuppressWarnings
documentation [API 2011],
As a matter of style, programmers should always use this annotation on the most deeply nested element where it is effective. If you want to suppress a warning in a particular method, you should annotate that method rather than its class.
...
Limit the scope of the @SuppressWarnings
annotation to the nearest code that generates a warning. In this case, it may be used in the declaration for the Set
.:
Code Block | ||
---|---|---|
| ||
class Legacy { @SuppressWarnings("unchecked") Set s = new HashSet(); public final void doLogic(int a,char c) { s.add(a); // Produces unchecked warning s.add(c); // Produces unchecked warning } } |
...
Because the return
statement is not a declaration, the Java Language Specification [JLS 2011] makes it impossible to suppress the warning trivially by using @SuppressWarnings
at that statement. Consequently, the @SuppressWarnings
is used over method scope where it is allowed. This can cause issues when some functionality that performs type-unsafe operations is added to the method at a later date [Bloch 2008].
...
This rule cannot be statically enforced in full generality; static analysis could be possible for some special cases.
Bibliography
[API 2011] | Annotation Type SuppressWarnings |
[Bloch 2008] | Item 24, "Eliminate Unchecked Warnings" |
...