File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Java in General and the fly likes Should @SuppressWarnings be used? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Should @SuppressWarnings be used?" Watch "Should @SuppressWarnings be used?" New topic
Author

Should @SuppressWarnings be used?

Giriraj Bhojak
Ranch Hand

Joined: Apr 03, 2008
Posts: 71
I really don't understand the usage of this annotation.
Isn't it a kind of fooling compiler that "I know a problem exists, but i don't want to fix the problem".
I have certain pieces of code where i have commented a section of code which refers to a variable.
But I haven't commented out the variable itself.
Hence i get "variable is never read locally" warnings.
I might uncomment that code in future and use the variable again.
So is it good to add @SuppressWarnings to the variable ?
Or should i just delete the variable itself?

More appropriately, when should @SuppressWarnings be actually used(or not used at all )?

Regards,
Giriraj.

Maneesh Godbole
Saloon Keeper

Joined: Jul 26, 2007
Posts: 9990
    
    7

You need to understand the difference between Warning and Error. Warning means you might run into trouble, whereas error means you are definitely in trouble!

Generics would be one reason to suppress warnings, or using deprecated API.


[How to ask questions] [Donate a pint, save a life!] [Onff-turn it on!]
Christophe Verré
Sheriff

Joined: Nov 24, 2005
Posts: 14687
    
  16

For unused variables, I'd prefer not to use SuppressWarnings, and put the variable into comment instead.


[My Blog]
All roads lead to JavaRanch
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 39535
    
  27
I think it's most appropriate when using an deprecated API from which you don't want to update. For example, for working with dates I prefer the Date class over the Calendar class; it works just as well, but is deprecated for the most part, so there are lots of warnings. That might be a good use.


Ping & DNS - updated with new look and Ping home screen widget
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19541
    
  16

@SuppressWarnings should also be used if you are really really sure that an unchecked cast will succeed. An example, from java.lang.Class:

The cast to (T) is 100% valid (the isInstance method has returned true), so in this case you can ignore the warning.

Another example:

Array.newInstance is guaranteed to return an array with component type "cls", and therefore the cast is safe. An example of its use:


Just make sure you write a comment to explain why you are sure the cast is safe.


SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
How To Ask Questions How To Answer Questions
Giriraj Bhojak
Ranch Hand

Joined: Apr 03, 2008
Posts: 71
So in my case I should comment out the variables rather than deleting them or adding @SuppressWarnings.
And should i also conclude that it is best to use them when deprecation is involved?
Paul Sturrock
Bartender

Joined: Apr 14, 2004
Posts: 10336

Giriraj Bhojak wrote:So in my case I should comment out the variables rather than deleting them or adding @SuppressWarnings.

I would say no. Commenting stuff out will hide it from any refactoring tools.

I'm a bit of a fundamentalist about this but I see @SuppressWarnings used to remove this sort of warning as a bad thing. If the variable is not used, delete it, otherwise it is just clutter. You can always add it back in when you have a use for it.


And should i also conclude that it is best to use them when deprecation is involved?

Yes. Use it to suppress warnings you can do nothing about.


JavaRanch FAQ HowToAskQuestionsOnJavaRanch
Giriraj Bhojak
Ranch Hand

Joined: Apr 03, 2008
Posts: 71
I'm a bit of a fundamentalist about this but I see @SuppressWarnings used to remove this sort of warning as a bad thing


Exactly Paul...
That is what I am trying to say that by adding @SuppressWarnings we are doing no good at all except fooling the compiler.
So remove the clutter as you have mentioned instead of hiding it.
Jelle Klap
Bartender

Joined: Mar 10, 2008
Posts: 1665
    
    7

Another valid use of the @SuppressWarnings annotation would be suppressing warnings reported by static analysis tools, when you don't want to disable the reporting rule in general.
For instance, PMD supports this annotation as part of its suppression mechanism. I know FindBugs doesn't, as it provides it's own SuppressWarnings annotation and ignores the standard one. Not sure about CheckStyle, but I believe it make use of this annotation, at least up to a point.


Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
Giriraj Bhojak
Ranch Hand

Joined: Apr 03, 2008
Posts: 71
I found one more usage...
As i was trying to clean up the code i found a private method in a class that was no longer being referred to.
I don't think i should have deleted the method(as some other developer from our team might have added it for some vicious purpose )
So i marked it with @SuppressWarnings.


Martijn Verburg
author
Bartender

Joined: Jun 24, 2003
Posts: 3274
    
    5

If the private method was no longer being referred to then it's pretty safe candidate for deletion (unless someone is doing funky Reflections) or at the very least throw a @Deprecated on it and remove it next cycle.


Cheers, Martijn - Blog,
Twitter, PCGen, Ikasan, My The Well-Grounded Java Developer book!,
My start-up.
Tom Stevns
Ranch Hand

Joined: Nov 20, 2001
Posts: 120
Hello !

"I'm searching for some best practices, documents links etc. concerning this topic !"


Nor do I like the use of @suppresswarnings.
But of course - there might be special cases where it can be helpfull.

I've run through a lot of Enterprise code from external consultants where approximately 30%
of the java files uses @suppresswarnings.

I think it's too much !!


Regards Tom Stevns, SCJP2
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19541
    
  16

I agree. I too try to prevent them as much as possible, and I also try to keep the scope as small as possible - local variables if possible, methods only if really needed (which should be never), never for classes.
Martin Vanyavchich
Ranch Hand

Joined: Sep 16, 2008
Posts: 241
You can find a guidelines about @SurpressWarnings in Effective Java Programming by Josh Bloch (2 edition) item 24. Eliminate unchecked warnings. It's copyright material, so I can copy paste it, but to sum up:

  • Eliminate every unchecked warning that you can.
  • If you can't eliminate a warning and you can prove that the code that provoked the warning is typesafe, then (and only then) suppress the warning with an @SuppressWarnings("unchecked") anotation.
  • Always use the SurpressWarnings annotation on the smallest scope possible.


  • You can find this book on google books, at least parts of it.

    Effective Java Programming look at page 116

    I hope I'm not violating any copyrights


    SCJP 6, OCMJD 6, OCPJWSD 6
    I no good English.
    Martijn Verburg
    author
    Bartender

    Joined: Jun 24, 2003
    Posts: 3274
        
        5

    Not in this case, it's something that Mr Bloch and Google will be discussing I'm sure. I'd certainly recommend that every Java developer owns a copy of this book, it's a Gem.
    Martin Vanyavchich
    Ranch Hand

    Joined: Sep 16, 2008
    Posts: 241
    Martijn Verburg wrote:I'd certainly recommend that every Java developer owns a copy of this book, it's a Gem.


    Could not agree more!
    Tom Stevns
    Ranch Hand

    Joined: Nov 20, 2001
    Posts: 120
    Hi All !

    Thank you very much !

    Your information are most usefull.
    Campbell Ritchie
    Sheriff

    Joined: Oct 13, 2005
    Posts: 36453
        
      15
    Martin Vanyavchich wrote: . . . I hope I'm not violating any copyrights
    Not sure, but I think you are probably all right.
    Mike Simmons
    Ranch Hand

    Joined: Mar 05, 2008
    Posts: 2969
        
        9
    While I agree with those here who dislike @SuppressWarnings in general, I think it's worth saying that sometimes, using it is not just unavoidable, but also 100% correct. Not just when handling legacy code, but also with the most up-to-date Java code. As shown in Rob's two examples above. Yes, you should try to find other techniques, if they exist, and minimize the scope of any @SuppressWarnings. But, if you've done that, and you still need to use it, then yes, use it, absolutely.

    Rob Prime wrote:Just make sure you write a comment to explain why you are sure the cast is safe.

    Mmmh, here I disagree with Rob, as well as Josh Bloch whom Rob quotes. I would say, make sure it's clear, in the code, why the cast is safe. But often, if you reduce the scope of the @SuppressWarnings enough, it's already pretty %$#@ing obvious that the cast is safe, and you shouldn't need to justify that. The two previous code examples given by Rob are good examples of this. Which may be why they do not, in fact, contain comments justifying the casts. None are needed.

    Now, from a language design perspective, I do think that having to use @SuppressWarnings is a bad smell, suggesting a problem with the language itself. But that's not a problem that Java programmer should have to concern themselves with in their day-to-day work, just trying to do their jobs. Just minimize the scope, put in the @SuppressWarnings, add a comment only if you were unable to make it obvious from the code itself, and move on. @SuppressWarnings is not something we need to apologize for. It's been forced on us by the language itself.
    Rob Spoor
    Sheriff

    Joined: Oct 27, 2005
    Posts: 19541
        
      16

    Mike Simmons wrote:
    Rob Prime wrote:Just make sure you write a comment to explain why you are sure the cast is safe.

    Mmmh, here I disagree with Rob, as well as Josh Bloch whom Rob quotes. I would say, make sure it's clear, in the code, why the cast is safe. But often, if you reduce the scope of the @SuppressWarnings enough, it's already pretty %$#@ing obvious that the cast is safe, and you shouldn't need to justify that. The two previous code examples given by Rob are good examples of this. Which may be why they do not, in fact, contain comments justifying the casts. None are needed.

    Perhaps you're right, and my phrase should be "make sure you document why the cast is safe". Code itself can be its own documentation in simple cases like my examples.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Should @SuppressWarnings be used?
     
    Similar Threads
    java.io quesion
    NullPointerException and createFault()
    Why the need for two-step array initialization?
    Strange behavior for enhanced ForLoop.
    Confusion with startElement,endElement and characters method