Community
Participate
Working Groups
3.1M4 I'd like to supress certain unchecked warnings. There's a special annotation for that, @SupressWarnings
The tricky problem here is that the list of official warning names is not spec'ed anywhere (afaik). So any decision we make is likely going to cause some grief. Unchecked ones are "unchecked", but there is little we can determine/reserve in general.
99% of time it's going to be used for the unchecked stuff anyway. So almost all uses will look like: @SupressWarnings({"[unchecked]"}) By allowing this you cover most ground and are compatible with javac. (although I think, as of now, it ignores the annotation, which is completely outrageous)
I discovered a few extra ones "deprecation", "finally". And given we have tons of optional ones, we are likely going to spec our names, which may conflict with the ones other vendors pick. But I agree this isn't a reason to at least not supported the few spec'ed ones.
As a comment on that: I realized that SuppressWarnings removes the warning from the Problems view in M4. However, the code annotation (icon at the left side of the editor and on the resource) remain. This is a bit missleading. I think either both should be removed or none (or there should at leats be an option in the preferences).
A related functionality which would be *really helpful* is the ability to suppress warnings for just a current line (or block). Use case - I depend upon the "unused parameter" warning for my own, and my team's code. Occasionally a parameter is intentionally unused (allowing for extending class use). I would like to be able to markup the parameter as allowed. Perhaps something like this: protected int calcWeight(Object data /*NO-WARN*/) { return 0; }
Brian, The SuppressWarnings annotation has ElementType.PARAMETER listed as a legal Target, so I don't think your unused parameter is a special case syntax-wise. i believe your code would look something like like: protected int calcWeight(@SuppressWarning("unused parameter") Object data) { return 0; } although, i'm sure the "unused parameter" string is incorrect. The list of acceptable strings is what they're discussing in the earlier comments.
Hi again. Is there still no way to remove the exclamation marks and yellow lines at warnings that are actually suppressed?
Not yet. Only workaround is to turn off offending warnings (or filter them out in problem view), which is not optimal.
*** Bug 89436 has been marked as a duplicate of this bug. ***
*** Bug 69505 has been marked as a duplicate of this bug. ***
*** Bug 71968 has been marked as a duplicate of this bug. ***
supposedly, the javac -Xlint parameters coincide with supported warning types. So all of: unchecked, deprecation, path, serial, fallthrough, finally and all should be supported. would need to verify with javac that it's the case (quite likely). javac website seems out of date. http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/javac.html seems to be missing some warnings kinds that running "javac -X" shows
Also see www.javac.info. I am planning to support many more warnings there.
Released initial support to HEAD. It currently recognizes: "all", "unchecked", "deprecation", "finally" and "serial".
Maxime - pls collect testcases from related defects. Currently, the annotation is checked for type and method/constr declarations.
Created attachment 20767 [details] CompilerOptions collects warning related options Created for use by test cases. In this version, the considered options are those that are related to an updateSeverity call into CompilerOptions.set(). There are 43 of these.
Created attachment 20768 [details] SuppressWarnings annotations tests Additional test cases. Some prepared for future support in the code (aka SuppressWarnings annotations on fields).
Added partial coverage, including the cases explicited in comments #14 and #15. Re. related bugs, prepared tests where support is not available yet, added tests where support is available.
In order to ease quickfix integration (suggest specific @SuppressWarnings), I am proposing to add following API to CorrectionEngine. Jeem - do you buy this API addition ? (sorry for indentation) /** * Returns a token which can be used to suppress a given warning using <code>@SuppressWarnings</code> * annotation, for a given problem ID ({@link IProblem }). If a particular problem is not suppressable, * <code>null</code> will be returned. * <p> * Note: <code>@SuppressWarnings</code> can only suppress warnings, which means that if certain * problems got promoted to ERROR using certain compiler settings ({@link IJavaProject#setOption(String, String)}), * the <code>@SuppressWarnings</code> annotation will be ineffective. * </p> * <p> * Note: <code>@SuppressWarnings</code> can be argumented with <code>"all"</code> so as to suppress * all possible warnings at once. * </p> * @param problemID * the ID of a given warning to suppress * @return a String which can be used in <code>@SuppressWarnings</code> annotation, or <code>null</code> * if unable to suppress this warning. * @since 3.1 */ public static String getWarningToken(int problemID)
Philippe, I'm fine with adding this. However, I would include a big disclaimer along the following lines: <p> <b>Note:</b> The tokens returned are not necessarily standardized across Java compilers. If you were to use one of these tokens in an @SuppressWarnings annotation in the Java source code, the effects (if any) may vary from compiler to compiler. </p>
Good suggestion.
Jeem - one more addition in the same area: I would like to offer an option to turn off @SuppressWarnings so as to allow clients to quickly revive all hidden warnings without editing any code. * COMPILER / Determine whether @SuppressWarnings is effective * When enabled, the @SuppressWarnings annotation can be used to suppress some compiler warnings. When disabled, all * @SupressWarnings are made inoperant, so as to revive all hidden warnings at once without editing code. * - option id: "org.eclipse.jdt.core.compiler.problem.suppressWarnings" * - possible values: { "enabled", "disabled" } * - default: "enabled"
Philippe, Sounds good. re: "When disabled, all @SupressWarnings are made inoperant, so as to revive all hidden warnings at once without editing code." I suggest wording it in a way that makes sense for batch compiling: "When disabled, all @SupressWarnings annotations are ignored; i.e., warnings are reported."
Read far better indeed. Thanks.
Last proposed addition: an optional warning to flag unhandled warning tokens. Given these are not standardized for current term, this could help users to find broken assumptions. * COMPILER / Reporting Unhandled Warning Token for @SuppressWarnings * When enabled, the compiler will issue an error or a warning when * encountering a token it cannot handle inside a @SuppressWarnings annotation. * - option id: "org.eclipse.jdt.core.compiler.problem.unhandledWarningToken" * - possible values: { "error", "warning", "ignore" } * - default: "ignore"
Sounds good. Given that all this is moot unless the source code contains @SuppressWarnings annotations, would it not be more helpful if the default is "warning"?
I thought of it, but considering there is no standard set yet, it would likely be a bit annoying in the short term. If others have an opinion on the default, I am open to suggestion.
All changes released to HEAD. Added AnnotationTest#test127-139. Fixed
Verified in I20050510-0010
