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.
Best Answer
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.