• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Should @SuppressWarnings be used?

 
Ranch Hand
Posts: 72
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.

 
Bartender
Posts: 11497
19
Android Google Web Toolkit Mac Eclipse IDE Ubuntu Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Sheriff
Posts: 14691
16
Eclipse IDE VI Editor Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
For unused variables, I'd prefer not to use SuppressWarnings, and put the variable into comment instead.
 
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Sheriff
Posts: 22783
131
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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?
 
Bartender
Posts: 10336
Hibernate Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Bartender
Posts: 1952
7
Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.


 
author
Posts: 3285
13
Mac OS X Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Ranch Hand
Posts: 123
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Posts: 22783
131
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Ranch Hand
Posts: 241
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Posts: 3285
    13
    Mac OS X Eclipse IDE Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • 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
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • 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: 123
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Hi All !

    Thank you very much !

    Your information are most usefull.
     
    Marshal
    Posts: 79177
    377
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • 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.
     
    Master Rancher
    Posts: 4806
    72
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • 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
    Posts: 22783
    131
    Eclipse IDE Spring VI Editor Chrome Java Windows
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • 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.
     
    reply
      Bookmark Topic Watch Topic
    • New Topic