Community
Participate
Working Groups
Some java files are generated (such as JLex files) and have many unused (i.e. never read) attributes. I would like to be able to disable these warnings on a file-by-file basis by using some special comments (pragmas) in those files. For example: /** * @@(pragma) warn -unused_attributes */
It should also be possible to just "locally" suppress warnings, i.e. not only on a file basis but just for specific occurences (or between special "brackets" or comments). E.g. I vey much appreciate the "field is never read" warning. Alas, our legals require us to have a COPYRIGHT = "..." string in EACH class. This string is of course never used and thus yields said warning. We normally declare these strings private since otherwise, e.g. when declaring them protected or public, when deriving from such a class, it causes another warning "foo.COPYRIGHT is hiding a field from bar". Since I have to keep the offending code as-is in my source code this causes ALL my files to be flag with a warning sign as well as generating tons of annoying "Problems" that I need to wade through to find signigficant entries. So, IMHO, the best solution would be, if the compiler could be told to just locally suppress that warning.
1.5 language is offering an annotation for this: @SuppressWarnings (which can take arguments for specific warnings).
I think that supporting the @SupportWarnings annotation is the best solution but the ability to suppress warnings on a per statment basis is necessary. Just the ability to suppress all warnings in a file is not really good enough.
Not disagreeing, but then the code would be polluted by meta comments, recognized by the compiler, like for // $NON-NLS1$ in existing code. Imagine how your code would look like with 50 different such tags... Also, agreeing on warning names across compiler vendors isn't something on the radar, so anything we would add would be very specific to our compiler implementation. This is why we have been reluctant to provide custom support. There is JSR(199) on compiler APIs which could provide some enhancements on this front.
I don't understand your comment Phillippe. If you supported @SuppressWarnings, that wouldn't be specific to the eclipse compiler, right? Its part of Java 1.5.
*** This bug has been marked as a duplicate of 83739 ***
