Summary of spring annotation usage

@SuppressWarnings("unchecked")
Explanation 1:  

       Shield some compile-time warnings.
        The compiler will give a warning when casting a type and
       add the

       program code

       @SuppressWarnings("unchecked")

       to not warn.

Explanation 2:

Comments Type This can be used to suppress warnings

when your coding may have warnings, such as security warnings,

as described in the api to

indicate that the specified compiler should be suppressed in the comment element (and all program elements contained within that comment element) warn. Note that the set of warnings to suppress in a given element is a superset of the warnings to suppress in all containing elements. For example, if you annotate a class to suppress one warning, and annotate a method to suppress another warning, both warnings will be suppressed in that method.

Depending on the style, programmers should always use this annotation on the innermost nested element, where it only works. If you want to suppress a warning in a specific method, you should annotate the method and not its class.

Explanation 3:

@SuppressWarnings

The last annotation provided by J2SE is @SuppressWarnings. What this annotation does is give the compiler an instruction to silence certain warnings inside the annotated code element.

A little background: J2SE 5.0 adds several new features to the Java language, and along with them many new warnings and promises to add more in the future. You can control whether these warnings are reported by adding the -Xlint parameter to "javac" (as shown in the @Deprecated section above).

By default, the Sun compiler outputs warnings as a simple two-line format. By adding the -Xlint:keyword flag (eg -Xlint:finally ) you can get a full description of keyword type errors. You can suppress the warning by preceding the keyword with a dash, writing -Xlint:-keyword. (A full list of keywords supported by -Xlint can be found on .) Here is a list:

keyword


purpose

deprecation warning when a deprecated


class or method is used unchecked warning when an

unchecked


conversion is performed, such as when When using collections, generics are not used to specify the type the collection holds.

fallthrough Warning


when a Switch block goes directly to the next case without Break.

Warn when path


has non-existing paths in classpath, source file path, etc.

serialWarning


when serialVersionUID definition is missing on a serializable class.

finally


Warning when any finally clause cannot be completed normally.

all


warning about all of the above.

The @SuppressWarnings annotation allows you to selectively suppress warnings in specific pieces of code (ie, classes or methods). The idea is that when you see a warning, you investigate it, and if you're sure it's not the problem, you can add a @SuppressWarnings annotation so you don't see the warning again. While it may sound like it will mask potential bugs, it will actually improve code security because it will prevent you from being indifferent to warnings—every warning you see will be worth noting.

Here is an example of using @SuppressWarnings to suppress deprecation warnings:

public class DeprecatedExample2 { @Deprecated public static void foo() { } } public class DeprecatedUser2 { @SuppressWarnings(value={"deprecation"}) public static void main(String[ ] args) { DeprecatedExample2.foo(); } }

The @SuppressWarnings annotation receives a "value" variable, which is an array of strings, indicating the warnings that will be suppressed. The set of legal strings varies by compiler, but on the JDK, it is the same set of keywords (very convenient) that can be passed to -Xlint. And ask the compilers to ignore any keywords they don't recognize, which is handy when you're using some different compilers.

Because the @SuppressWarnings annotation takes only one parameter and uses the special name "value" for that parameter, you can choose to omit value= as a convenient abbreviation:

public class DeprecatedUser2 { @SuppressWarnings({"deprecation"}) public static void main(String[] args) { DeprecatedExample2.foo(); } }

You can pass any number of string values ​​in a single array parameter to the annotation, and place annotations on any level. For example, the following sample code indicates that deprecation warnings will be suppressed for the entire class, but only unchecked and fallthrough warnings within the main() method code:

import java.util.*; @SuppressWarnings({"deprecation"}) public class NonGenerics { @ SuppressWarnings({"unchecked","fallthrough"}) public static void main(String[] args) { Runtime.runFinalizersOnExit(); List list = new ArrayList(); list.add("foo"); } public static void foo() { List list = new ArrayList(); list.add("foo"); } } Is @SuppressWarnings

more useful than the first two annotations? Absolutely. However, the annotation is not yet fully supported in JDK 1.5.0, and if you try it with 1.5.0, it will behave like a no-op. Invoke -Xlint: -deprecation also has no effect. Sun has not stated when support will be added, but it has hinted that this will be implemented in an upcoming dot release.

Go one step further

If you try to look at these properties in the Javadocs page, you may have trouble finding them. They are located in the core java.lang package, but are somewhat hidden, and they appear at the very bottom of the Javadoc class, listed after Exceptions and Errors.

Notice the strange @Target and @Retention annotations appended to the SuppressWarnings annotation? These are called metadata annotations, and they describe where that annotation applies. I'll cover them and how to apply metadata annotations to your own annotations in the second article in this series.