RFR: 8003380 - Compiler warnings in logging test code

Jim Gish jim.gish at oracle.com
Wed Nov 28 18:51:24 UTC 2012


Since we don't yet have a resolution on this, I modified the test code 
in question to remove the @SuppressWarnings("unused") and actually 
removed the unused references (and retested, of course).

Please review 
http://cr.openjdk.java.net/~jgish/Bug8003380-logging-test-warnings/ 
<http://cr.openjdk.java.net/%7Ejgish/Bug8003380-logging-test-warnings/> 
and if ok, Chris, could you please go ahead and push the changes?

thanks,
    Jim


On 11/28/2012 01:27 PM, Jim Gish wrote:
> Here's the list of @suppresswarnings values that are recognized by 
> Eclipse Juno:
>
>
>    Excluding warnings using @SuppressWarnings
>
> Since Java 5.0, you can disable compilation warnings relative to a 
> subset of a compilation unit using 
> the|java.lang.SuppressWarning|annotation.
>
>  @SuppressWarning("unused") public void foo() {
>   String s;
>  }
>
> Without the annotation, the compiler would complain that the local 
> variable|s|is never used. With the annotation, the compiler silently 
> ignores this warning locally to the|foo|method. This enables to keep 
> the warnings in other locations of the same compilation unit or the 
> same project.
>
> The list of tokens that can be used inside 
> a|SuppressWarnings|annotation is:
>
>  * allto suppress all warnings
>  * boxingto suppress warnings relative to boxing/unboxing operations
>  * castto suppress warnings relative to cast operations
>  * dep-annto suppress warnings relative to deprecated annotation
>  * deprecationto suppress warnings relative to deprecation
>  * fallthroughto suppress warnings relative to missing breaks in switch
>    statements
>  * finallyto suppress warnings relative to finally block that don't 
> return
>  * hidingto suppress warnings relative to locals that hide variable
>  * incomplete-switchto suppress warnings relative to missing entries in
>    a switch statement (enum case)
>  * javadocto suppress warnings relative to javadoc warnings
>  * nlsto suppress warnings relative to non-nls string literals
>  * nullto suppress warnings relative to null analysis
>  * rawtypesto suppress warnings relative to usage of raw types
>  * resourceto suppress warnings relative to usage of resources of type
>    Closeable
>  * restrictionto suppress warnings relative to usage of discouraged or
>    forbidden references
>  * serialto suppress warnings relative to missing serialVersionUID
>    field for a serializable class
>  * static-accessto suppress warnings relative to incorrect static access
>  * static-methodto suppress warnings relative to methods that could be
>    declared as static
>  * superto suppress warnings relative to overriding a method without
>    super invocations
>  * synthetic-accessto suppress warnings relative to unoptimized access
>    from inner classes
>  * sync-overrideto suppress warnings because of missing synchronize
>    when overriding a synchronized method
>  * uncheckedto suppress warnings relative to unchecked operations
>  * unqualified-field-accessto suppress warnings relative to field
>    access unqualified
>  * unusedto suppress warnings relative to unused code and dead code
>
> (From 
> http://help.eclipse.org/juno/index.jsp?topic=/org.eclipse.jdt.doc.isv/guide/jdt%255Fapi%255Fcompile.htm)
>
> Jim
>
> On 11/16/2012 10:02 PM, Stuart Marks wrote:
>> On 11/16/12 6:39 PM, Stuart Marks wrote:
>>> The background is that the words that can be supplied to 
>>> @SuppressWarnings
>>> reside in an uncontrolled namespace. The JLS [1] defines only 
>>> "unchecked" and
>>> any others are compiler-specific. The set of words accepted here by 
>>> javac is
>>> the same as the words defined for -Xlint.
>>>
>>> [1] 
>>> http://docs.oracle.com/javase/specs/jls/se7/html/jls-9.html#jls-9.6.3.5
>>
>> Whoops, the JLS defines "deprecation" as well (as Alan pointed out in 
>> another thread the other day). But the rest of the point stands.
>>
>> s'marks
>

-- 
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com




More information about the core-libs-dev mailing list