RFR: 8003380 - Compiler warnings in logging test code

Chris Hegarty chris.hegarty at oracle.com
Thu Nov 29 12:34:00 UTC 2012


and pushed...
   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2b829a5a46ee

-Chris.

On 11/28/2012 06:51 PM, Jim Gish wrote:
> 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