File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Should @SuppressWarnings be used?

 
Giriraj Bhojak
Ranch Hand
Posts: 72
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 10971
11
Android Eclipse IDE Google Web Toolkit Java Mac Ubuntu
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Christophe Verré
Sheriff
Pie
Posts: 14691
16
Eclipse IDE Ubuntu VI Editor
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For unused variables, I'd prefer not to use SuppressWarnings, and put the variable into comment instead.
 
Ulf Dittmer
Rancher
Pie
Posts: 42966
73
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Rob Spoor
Sheriff
Pie
Posts: 20381
46
Chrome Eclipse IDE Java Windows
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
@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.
 
Giriraj Bhojak
Ranch Hand
Posts: 72
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 10336
Eclipse IDE Hibernate Java
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Giriraj Bhojak
Ranch Hand
Posts: 72
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1951
7
Eclipse IDE Java
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Giriraj Bhojak
Ranch Hand
Posts: 72
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3275
5
Eclipse IDE Java Mac OS X
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Tom Stevns
Ranch Hand
Posts: 122
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 !!

 
Rob Spoor
Sheriff
Pie
Posts: 20381
46
Chrome Eclipse IDE Java Windows
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 241
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
     
    Martijn Verburg
    author
    Bartender
    Posts: 3275
    5
    Eclipse IDE Java Mac OS X
    • 0
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Posts: 241
    • 0
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Posts: 122
    • 0
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi All !

    Thank you very much !

    Your information are most usefull.
     
    Campbell Ritchie
    Sheriff
    Pie
    Posts: 47274
    52
    • 0
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Posts: 3028
    10
    • 0
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Pie
    Posts: 20381
    46
    Chrome Eclipse IDE Java Windows
    • 0
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic