Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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
bgColor#ccccff
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"

...