RFR: 8003380 - Compiler warnings in logging test code (original) (raw)

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