How to specifically suppress "Comparing identical expressions" in Eclipse-Helios JDT

Question

I tried annotating the enclosing method with

    @SuppressWarnings("compareIdentical")

but this does not work (worse yet, the annotation results in its own Unsupported @SuppressWarnings("compareIdentical") warning!)

I know that I can always use

    @SuppressWarnings("all")

but that'd be more warning-suppression than I want.

FWIW, I got the "compareIdentical" string from the "Warning Options" table in http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.jdt.doc.isv/guide/jdt_api_compile.htm (a hail-mary pass, to be sure).

Thanks!

Phagocytosis

Just out of curiosity: Can you post the bit of code where you perform the compare? I shouldn't know for what I should use it. – Rahm

"Comparing identical expressions" happens when you set a final boolean as true and then you try some test like if(CONST==true). Or the similar but setting as false. – Landy

By the way, the fact that there is no way to surpress it seems to be an open eclipse bug: bugs.eclipse.org/bugs/show_bug.cgi?id=397971 – Landy

Also happens with int's and maybe other types. Example: final int i = 10; if(i==10); – Landy

This is really nasty. I would like to assert(OneModule.KNOWS_A_VALUE == OtherModule.KNOWS_THE_SAME_VALUE) just to make sure that future adaptions of this code are done in a consistent matter. Imagine that both modules are in different libraries that might be used alone, so they can't get the knowledge from a common source. The example is of course over simplified. – Qatar

Answer 1

Officially, there are only 3 supported arguments to @SuppressWarnings(), as specified by the standard $9.6.4.5:

• Unchecked warnings (§4.8, §5.1.6, §5.1.9, §8.4.1, §8.4.8.3, §15.12.4.2, §15.13.2, §15.27.3) are specified by the string "unchecked".
• Deprecation warnings (§9.6.4.6) are specified by the string "deprecation".
• Removal warnings (§9.6.4.6) are specified by the string "removal".

But, in small text, the standard mentions support for extra types:

For other kinds of warnings, compiler vendors should document the strings they support for @SuppressWarnings. Vendors are encouraged to cooperate to ensure that the same names work across multiple compilers.

These are supported by some compilers:

• all to suppress all warnings
• boxing to suppress warnings relative to boxing/unboxing operations
• cast to suppress warnings relative to cast operations
• dep-ann to suppress warnings relative to deprecated annotation
• deprecation to suppress warnings relative to deprecation
• fallthrough to suppress warnings relative to missing breaks in switch statements
• finally to suppress warnings relative to finally block that don't return
• hiding to suppress warnings relative to locals that hide variable
• incomplete-switch to suppress warnings relative to missing entries in a switch statement (enum case)
• nls to suppress warnings relative to non-nls string literals
• null to suppress warnings relative to null analysis
• raw to suppress warnings relative to usage of raw types
• restriction to suppress warnings relative to usage of discouraged or forbidden references
• serial to suppress warnings relative to missing serialVersionUID field for a serializable class
• static-access to suppress warnings relative to incorrect static access
• super to suppress warnings relative to overriding a method without super invocations
• synthetic-access to suppress warnings relative to unoptimized access from inner classes
• unchecked to suppress warnings relative to unchecked operations
• unqualified-field-access to suppress warnings relative to field access unqualified
• unused to suppress warnings relative to unused code and dead code

So, there is nothing which might help you.

Rahm