I use @SuppressWarnings("unchecked") and @SuppressWarnings("null") mostly above methods to let the code compile without any warnings but I have my doubts. Found this Stackoverflow question. Jon Skeet wrote an answer to it which I find intriguing.
According to him,
Sometimes Java generics just doesn’t let you do what you want to, and you need to effectively tell the compiler that what you’re doing really will be legal at execution time.
But what if there is a chance that an exception will be thrown? Isn’t suppressing warnings a bad idea then? Shouldn’t I be aware of the places where problems could surface?
Also, what if someone else modifies my code later and adds some questionable functionality without removing SuppressWarnings? How can that be avoided and/or is there any other alternative to this?
Should I be using @SuppressWarnings("unchecked") and @SuppressWarnings("null")?
Update #1
As far as unchecked type casts go, according to this answer (pointed out by @gnat in the comments below), suppressing these warnings is necessary.
Many indispensible Java libraries have never been updated to eliminate the need for unsafe typecasts. Suppressing those warnings is necessary so that other more important warnings will be noticed and corrected.
In case of suppressing other warnings, still in a bit of a grey area.
Update #2
As per Oracle Docs (also mentioned by some answers below):
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.
4
To me, the entire point of suppressing warnings is to maintain a “clean bill of health” for your project. If you know that your entire code base compiles cleanly, it’s immediately obvious when someone does something wrong that causes the first warning to appear in the issues list. You can then fix the error or suppress it if you can prove that it’s spurious.
But if you have 21 warnings in there to begin with, it’s much more likely that you’ll overlook the 22nd one when someone causes it, and you don’t check that it’s harmless. That means that problems can creep into your code base and you’ll never notice.
Warnings are useful items of information. Make sure you heed the ones that speak the truth, and filter away the ones that don’t. Don’t let people commingle the two kinds so that you lose your early warning system.
Edit
I should probably clarify that suppressing a warning that does have merit is a silly thing to do. A clean bill of health that you obtained by cheating is obviously worth nothing. Given the choice, you should always fix the problem the compiler noticed rather than just close your eyes to it. However, there are areas in which the compiler cannot be sure whether something will be a problem or not (Java’s generics are one such area), and there the better choice is to review each such instance and then suppress the warning in this specific place rather than to switch off this class of warning altogether and potentially miss a genuine one.
2
Suppressing warnings is something that needs to be done with extreme care.
A warning means: The compiler found something that looks dodgy. It doesn’t mean it is dodgy, it just looks like it to the compiler. Sometimes you have code that is perfectly fine and gives a warning. Sometimes you fix it by slightly modifying your code. Sometimes the compiler has some feature specifically for that purpose. For example where
if (x = someFunction ()) { ... }
gives a warning but
if ((x = someFunction ())) { ... }
doesn’t. In the first case a warning assuming that you possibly meant == and not =. In the second case no warning because the extra parentheses tell the compiler “I know what I’m doing”. Better of course would be
if ((x = someFunction ()) != 0) { ... }
or using two lines.
And sometimes, very rarely, there are cases when your code is fine but you can’t manage to write it in a way that is accepted without warning. In that very, very rare case you disable a warning for that statement and turn it on immediately afterwards. That’s a last resort. And you only disable that specific warning, no others.
However, some people just disable warnings to get rid of warnings, because they are too lazy to find out and fix the reason for a legitimate warning first. Or they don’t even try to write code that is free of warnings. That’s an extremely unhealthy thing to do.
2
Suppressing warning for an entire method is suspect. Better to suppress the warnings for the specific line, with a comment. e.g.
@SuppressWarnings("unchecked") Foo foo = (Foo)object; // Using old library requires this cast